Help with creating a base interface for my classes

I want to create an interface or base class (not sure I want to go this route) for all my business entities. For each business entity I need the following:

• Id - primary key of the entity
• Type - type of the entity, e.g. User, just a string
• Name - name of the entity, e.g. John Doe
• Description - short description of the entity, e.g. Senior Programmer
• CreatedDate - date the entity was created
• ModifiedDate - date the entity was modified

All classes support a single primary key.

Most of my classes have these fields, though in most cases, the primary key would be something like UserId.

One of the reasons I want to create some commonality in my business entities is I want implement a search function that returns a list of IEntity (or Entity class, if leveraging inheritance) objects.

My questions are ...

• Is is the more correct way to leverage an interface as opposed to a base class?
• If I do create this as an interface should I keep the property simples, e.g. Id and Name ... which would minimize me having to code each property implementation OR is it better to append "Entity" to each proper name so it's easier to work with the business entity, e.g. MyEntity.Ent开发者_JS百科ityId verses MyEntity.EntityId

I realize this could be considered subjective, but I really need to get some guidance on this, so any ideas to make this not be so subjective would be much appreciated.

Thanks in advance!

In my opinion...

If your classes are going to have some common implementation of some of their methods, then a base class makes more sense. Because you can't implement inside an interface, and if you were to implement an interface, you'd have the same common implementation in multiple classes, instead of a single base class.

I think appending "Entity" to each property is pointless. You already imply that it's an entity property by either the name of the entity object or its underlying type. I say avoid redundancy and keep it simple.

In my opinion, if you want many objects to have this functionality, you should avoid base-class inheritance at all costs. Once you decide that you're gonna inherit all of the classes in your project from a certain base-class, it's hard to go back. Remember, C# only lets you have single-inheritance.

A better solution might be to implement an interface which lets classes specify the properties they have to anyone who might be interested in those data.

Another reason to avoid base-classing is that it's going to be harder to unit-test, if your'e interested in that. It's also going to be hard to change custom behaviors without affecting many areas of your application.

In short, what you can do is have objects which you have clearly recognized as needing that interface implement that interface, and have another manager-type class ask for that information from those other classes, and be the adapter or gateway between your modular, single-purpose objects, and a database (or something like that).

Hope I've made myself clear enough.

Consider whether it would be better to keep the business data as isolated classes in your data access layer, and provide a common wrapper in your presentation layer that provides the common feature set you're thinking about. Maybe your solution isn't complicated enough to warrant a fully-tiered architecture - which I'm sure quite a few people would disagree with - but I feel that making your application tiered is a good approach. This means that the data access classes get to be seperate, avoiding the conundrum altogether at this tier, and the presentation class(es) only expose the functionality you actually need - but take on whatever inheritance regime you choose. My reasoning is that considering the problem in this way might make it easier to decide.