Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

>> Robert Martin wrote:
>
> I agree that assertion is worthless without reason. So, here are my
> reasons, based on 30+ years of software development experience. (Which
> may be completely bogus because of what my great-god-father sang while
> welding panels on the Titanic)
>
> Databases are data centric. While they have behaviors; those behaviors
> are related to data management. Applications are behavior centric,
> while they manipulate data, the things that do to that data are rich
> with business rules and formatting behaviors.
>
> Behavior and Data have different constraints. Data must be usable by
> many different applications. Therefore the structure of the data must
> accommodate all applications, and cater to those that are most
> important. Changes to the database must be carefully considered so as
> not to break existing applications.
>
> Applications are generally independent of each other (although they
> often communicate indirectly through the DB). Changes to applications
> have much to do with behavior and formatting, and not so much to do
> with data.
>
> Since the forces that change databases and applications are different,
> and their customers are different, they should be designed for these
> different environments and constraints. An application should be
> designed such that it's modules are flexible and easy to change. A
> database should be designed such that it's changes to it's structure
> minimize impact on all the applications.
>
> If an application depends strongly on the database structure, then the
> structure of its behaviors will be coupled to the database structure.
> Since this structure is a result of catering to many different
> applications, each application will have an indirect coupling on all
> the others. Or to say this a different way, the application will not
> be able to use the data structures that are most favorable to its
> algorithms because it is coupled to the DB whose data structures are a
> compromise between all applications.
>
> If, on the other hand, the applications are designed to be independent
> of the database structure, then the applications can use whatever data
> structures are appropriate for their algorithms.
>

Though I agree with the base concept that Mr. Martin is driving at, I think the application is not quite right. In a well designed program, of sufficient size, incorporating all of the behavior of a particular object can make the object large and complex. To mitigate this, various behaviors (and data) can be factored out of the object. Consider a customer object: The code that displays the customer can be factored out into a UI object (and maybe partially reused for other objects, maybe not). The code that checks to see if the customer is valid or in good standing can be factored out into a business rule object. The code that handles the persisting of the customer can be factored into a data layer object. To even further mitigate complexity, behaviors and data can be handed of to other applications. In this case the functionality deals that with an external program itself can be factored out. Interface objects can be made to manage the particulars of connecting to that external program. In this case, the interface between the database and the executable is what is being discussed here at GREAT length. The same conversation could be had if one of the fields in the customer was their credit score and it had to be retrieved from an external web service (and possibly cached). In such a case, a developer would most likely create a class to manage that interface.

Putting all the interface logic in one place make sense on several levels. From an organizational viewpoint, you know where to find it. If the data is being supplied by the database properly, but the program is displaying the wrong data, then you might want to check the either side of the interface. Another benefit is that the application on either side of the interface can be swapped out for another and only the code in the interface has to change (which has been mentioned and argued). When creating test cases (either before or after coding...that's an argument for another time and place phlip! :) ). The testing of the external program can be done by testing the interfaces. And I'm sure there are more benefits I missed.

It may seems obvious to a OO developer to put the business rules and the interface rules in the OO code and the data access code in the DBMS, this is not the ONLY solution. I hear the DB people saying that there are a lot of business logic that not only CAN be done in the database, but is more efficient to do on the database side. I couldn't agree more and this is my experience as well. SQL is VERY well suited for some tasks and OO for others. (see the many arguments on both sides earlier in the thread).

I've have worked on projects where all the business logic was in the DBMS and others where it was all in the application. Both worked and both had their drawbacks. But BOTH had interfaces clearly defined at the application boundaries. It is, IMHO, very important to separate presentation, business, and data retrieval logic in complex systems. In the system where the business logic was all in the DBMS, the logic for combining the data and getting it from various tables was stored in views. The business logic was stored in stored procedures. They were kept just as separate as I would have kept them if all the work was done in an OO application. The stored procedures and views that were accessed by the application where separated from the ones that provided internal intermediary results (by naming convention).

I even worked on a 4GL (or 5GL based on your definition of GLs) where all the presentation, business, and data access logic was in the DBMS system. There too, the presentation logic was separated from the rest of the logic. I felt that the system could have been a lot easier to interpret and modify if the business logic and the data access logic had been separated but this, sadly, wasn't the case.

In short, I agree with the separation of behaviors, but there are times when that separation might not always be cleanly at the database/application boundary. There are many time when, for efficiency reasons, there might need for parts of the business logic to reside in the application, parts in the DBMS, and even perhaps parts in another application (i.e. a payroll system in my customer example). Just as a database might be de normalized to increase efficiency, the idea of one object, containing all data and behavior frequently needs to be broken down to increase efficiency and apply "divide and conquer" techniques for implementation.

I think Mr. Martin's proposed technique is a great place to start a architecture, but by the time the final design of a system is put together, it should not be surprising if isn't realized.

Closely related to this...

In comp.object, frebe wrote:
> I have always been amazing of the fact
> that when OO was introduced, the main argument was that data and
> behavior was bundled together, but in OO of today the main thing is to
> separate data and behavior (like it was before OO was introduced).
>

I am amazed and sometimes confused by his as well, but on closer examination, it isn't that the case that the data and behavior really needs to be seperatated. Instead, as I point out above, it is a matter of the behaviour and data of a single object becoming so complex that it needs to be partitioned. I think it is an error to try to seperate all the data from the behaviour. However, the behaviour of persisting, (and the data required to do so. i.e. table names, database names and locations.), can be seperated out from the behaviour of displaying (and the data that is required: i.e. screen location, colors), and the behaviour and data that is common can be seperated into another object.

-Scott Frye
Scottf3095_at_aol.com