Base business class: is it bad?

Question

Hello,

I would like to create my base business class, something like EntityBase, to have some common behavior, such as implementing interface to track changes in the object (IsNew, IsDirty) and INotifyPropertyChanges interface.

But many people say it's a bad idea to have a base business class and derive all your business objects from it. Usually they say that it is bad to have presentation code in the entity class. But I think it's just a theory. What is bad in practice? They say: try it yourself. No more arguments usually.

So what do you guys think? Is it good or bad? If bad, why? Please, try to be a practical person, not theoretic.

Answer 1

It's bad. We had this for several years, and there was nothing we could put in our base class that was generic enough that it applied to all inherited classes.

Answer 2

A lot of people subscribe to the idea of Single Responsibility Principle, which says that a class should only have a single area of responsibility. By building state tracking, rendering and so forth into a common base class, you'll certainly violate the SRP. If you class handles many tasks, it will have many reasons to change.

Answer 3

Maybe it's not the most elegant solution from the standpoint of object oriented design, but if you are going to use data binding, it's often a good idea to implement INotifyPropertyChanged in a base class. This way you can minimize the burden of having to implement it in all your entities.

In the case of change tracking you should take a look at the Unit of Work pattern if you want to separate that responsibility from your base class, although it's very common to see change tracking implemented as you point out in .net applications that don't rely in an ORM.

Answer 4

I don't think that it's necessarily bad to have a set of interfaces and base classes implementing those interfaces that provide some common functionality that you want in your business entities, if your business entities aren't required to derive from those base classes. This gives you flexibility in your implementation while providing convenience of implementation.

For example, I have an IValidatedEntity interface that gets applied to just about every business object that I create. It requires that the business object implement some validation rules. However, my audit objects are only created internally and I use unit testing to make sure that I can't create invalid audit objects so these classes don't implement the IValidatedEntity interface

Most of my classes that take input from the web AND contain string data derive from a XSSValidatedEntity class (which implements the IValidatedEntity interface), but provides XSS checking via an HTML parser to prevent injecting HTML into the database. For most of my classes this works fine, but in those instances where I want to allow limited (safe) HTML, I obviously can't derive from this class.

Answer 5

What you are describing sounds more like a presentation object, yet the IsDirty and IsNew could also be used in a domain model as well. Before deciding on what to include in your base objects you should have a clear picture of what the business requirements are. Focusing on the business objects for a moment, how static will the requirements be? Do you have a grasp on all your rules that govern how the objects will interact, and will those rules change? If they change, how often? This may prove the most challenging for you

You may find that depending on the application, the bulk of your work should come from implementing the business process, and therefore the architecture of the CRUD functionality. while being important, is not the focus of your efforts. In other other words, your business objects will support the concepts of the business process, and not include IsDirty. Your Data Access Layer can then concentrate on the state of the records and determine whether to Insert or Update data.