Building up a good business library is art. Because every bad decision made early will eat project’s time later. Bad decisions will also waste many time of developers who have to use this library in their work. One of the most common mistakes made is mixing DAL functionality to business objects. At first it may seems like a good idea – why not have a smart objects? – but as project goes this solution causes more and more problems. And, be warned, each next problem is worst than previous.
Well, the correct answer to this problem is n-tier architecture and design patterns (in most cases), but let’s see how bad can be too smart business class. By the way, notice how hard are problems going everytime we make one step forward.
Seems like a good idea
Well, project is started and it is time to create classes for business objects. To save some coding time the team decides to make objects as smart as possible. The point is – application programmers who have a lot of work to do can use those objects and doesn’t have to worry about how these objects are persisted and restored after persisting.
So, seems like this class is okay. We can modify it easily and if it is necesaary we can save this object or delete it. Very convenient.
Let’s see what happens
First problem rises when somebody wants to extend one of those business classes. Methods dealing with data get override, some guys call base methods in overrides and some guys just write new logic without calling corresponding method of base class. It is done economically: let’s use as much base class features as possible. Sometimes it is possible, sometimes it isn’t.
Let’s see what kind of trouble our guys are building and let’s look at the near future. Let’s see what happen three months later. The number of classes is not small anymore and there are couple of hundred business classes. Inheritance hierarchies are much longer than before and there are many problems with data access. Nobody has good picture of what is happening inside those override methods. Nobody knows what classes call base class methods and what classes have their own logic.
There are many problems related to data access and time losses are heavy. When problems were small then these problems were solved by simple hacks. Now there are hundreds of simple hacks and the code is out of control.
And even worse scenario
Let’s suppose that in the beginning of project there was made one important decision about required web service: let’s write the service later when business classes don’t change anymore or when changes are at least very small. Now, how to show these business objects to web services? All those objects must be serializable. But how can one serialize live communication resources like database connections?
Okay, let’s say that writing hundreds of DTOs is solution. Maybe it is but I doubt about it. Still there is need for wrapping business objects because it is not possible to send them over network. And this wrapping maybe pretty expensive job to do for server.
This storty ends with web service hack because there is not time enough to rewrite business layer from the ground. There is time for fast hacks but who guarantees that these hacks will work?
Be careful when you are making decisions about system architecture and design. If something seems very smart then check it over many times to make sure you don’t create the small problem that grows larger exponentially in time.
View Comments (8)
I think you're confusing things a bit here. Business objects do not need to contain database persistence logic. That's for repositories to handle, and they are accessed via interfaces. Your business objects ("Entities") should be POCO. No persistence logic in them at all, just properties and "business logic". Business logic is NOT data logic.
No, I don't confuse. I talk exactly about why too smart business objects are WORST thing ever to do. I just describe the rotting process of project when too smart business objects are used.
If you want to describe bad thing as best as you can then talk about consequences. It is otherwise not very clear why one or another thing is bad :)
i agree with u, i am a good dba and very strong asp.net developer. I have seen ppl keep spending time fixing their smart object. and what even worse, if another developer take over, then f***..
so the rule to software is to make the code as readable as possible, and maintainable...and I can tell you many database design patterns violate this rule. I use the most old school, but most simple database access method, no database persistance or object mapper... As a result, I do not invent more code to dig a hole for myself, Many people said it is bad because the object is not smart.. but if is too smart, more trouble happens
I have to tell u mixing up dal and business logic is a good idea. there are many operations where database is performed at its best...Performance of the database is a disaster if putting all business logic in bal..... as a dba, 9 out of 10 developers do not know the trick of query optimisation, and writing buinsess logic in bal violates query optimisation in many scenarios
I am not a poor developer, I can tell I am almost the top 5% of people in technical skills..
Being in the bottom 95% of developers, I can't understand a single point you are making. I do know however, that global statements of truth are always wrong....... except that one.
Don't pay attention to the guy who is about to post
I work with Jose, and I can verify that he is definitely in the bottom 95% of developers.
Good article for developers who are designing N-Tier APIs. It alerts them with possible future big problems when initial design is not good.
It would be good to show best design patterns or at least best designing practices.
Way to toot your own horn there, buddy. Your comment demonstrates that you have no clue what you're talking about. Maybe if you take a break from thinking that you're awesome, you'll gain enough humility to learn what you're talking about. I certainly wouldn't hire you based on that comment. You epitomize the arrogant know-it-all types that give our field a bad name.