Object Layers Are Bad

Obviously, I do not mean that business objects are bad. It’s just that I have recently seen code that iterates through collections to find records – basically, I have seen classes and methods used to perform the work that SQL was designed to do. I have seen objects that do work that should be done with triggers or stored procedures.

Of course, using triggers can tie the solution to a specific database implementation or vendor. However, some clients are clearly committed to their database vendor – also, they may already have code that ties them to a specific database implementation. Use the database for what it does well! SQL is standard – why reinvent the wheel?

Many teams code as if the database and the application are of a piece – they are not. It is conceivable that one database may be used by multiple applications or web services in the future. Why make it necessary to maintain business logic in each application? Implement it in the database, I say.

Also, it is easier to migrate to another technology if the database is robust. The application should implement business processes, display data, generate reports and collect information. Basic data validation should be done by business objects before data is passed to the database, but why clutter an application with complex business objects and misapplied design patterns? Keep things simple. It costs money to maintain code. Make it readable. Make it possible for new developers to get up to speed quickly.

Why provide a complex solution to a simple problem. There are so many young and clever coders out there who are too clever for their own good. Agility is more than a process – agility is the result of good planning, of simplicity. Write code so that it can easily be understood and maintained. That’s my rant.