Too-Smart-Business-Object Anti-Pattern

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.


NB! This blog is moved to

Click here to go to article


  • 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 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..

  • Interessante Informationen.

  • 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.

  • Hi Gunner,

    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.

  • @Ben:

    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.

Comments have been disabled for this content.