Is using a root persistent class or base persistable object an architecture smell?

One of the major gripes voiced by the Alt.Net community against the Microsoft Entity Framework is that it forces you to use a Base Persistable Object for everything being stored in the database. I have two questions related to this:

1. Is it acceptable to have a "Root Persistent Class" as the base for the domain objects in your application, or is this an architecture smell?

2. If you feel it is OK for you to have one within your application, is it also OK for an ORM framework to force you to use one? Are there开发者_StackOverflow社区 reasons to avoid a framework that makes you do this?

I've been using an abstract base object as the root of all my peristable classes for some time. It makes several housekeeping chores much easier.

My feeling is that it's ok presuming the context is such that it

1. stays out of the way
2. doesn't add features that aren't used outside of the scope of the entity
3. doesn't tie you to any particular ORM (sort of in keeping with #2)

So if the base class is used to describe, for instance, an ID and the meaning of Equality (since many times entities are considered equal if they have the same ID), then that's fine. However, when it starts describing database-centric information (such as tables, columns, state of the entity, etc), then yes, I think it begins to smell.

For applications with a low-to-moderate level of complexity, using a base persistable object can really increase development productivity.

However, doing so constrains your code and limits design options as your application gets more complex. Obviously, you use up your base class at the start, which is significant in C# and Java. It also promotes poor separation of concerns.

I'd say the most important thing when considering any ORM is to ask these questions (from Jeremy Miller's article The Unit of Work Pattern and Persistence Ignorance):

• Can the Business Logic Run Independently of the Database?
• Can I Design My Domain Model Independently from the Database Model?
• How Does My Persistence Strategy Affect My Business Logic?

Unless you are using Data Transfer Objects (DTO) for persistence and using that model, having a root object for persist-able classes in my experience greatly decreases code repetition and increases developer productivity. And even when using a DTO, I think it could be helpful though I rarely use DTOs so can't speak from experience.

I would not consider it code smell for the following reasons:

1. Increase in productivity of developers.
2. Consolidates persistence code in one class.
3. Easy to change to another framework that implements the same methodology (have to only change inheritance of all your business classes, and update checks of the original root class).

Edit: Inline statichippo's answer, I agree with his opinion about this base class including information about the underlying data storage mechanisms (such as table/column names, database type, etc).