Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"

On 2007-01-23 11:30:27 -0600, "topmind" <topmind@xxxxxxxxxxxxxxxx> said:

Robert Martin wrote:

In any application, OO or not, this translation must take place. All
we have done with the code in the book is to assign a place for that
translation.

First off, this could be done without OOP. We could have functions that
wrap the SQL. Thus, it is not really an OO-specific thing.

I quite agree. OO is just one of many potential technologies for separating concerns. It happens to be one that is both popular an effective.

There is no duplication. There is no waste. There is simply a
separation of concerns. Those concerns would exist regardless of
whether they were separated or not.

It is additional code and likely additional work.

Very little "additional" code. Indeed, it might even be less code since all the SQL is concentrated in one place rather than spread out and duplicated. We can argue about whether the net work is greater or less. From my point of view it is significantly less since I can forget about the SQL and Schema while dealing with the business rules and interface.

The more beurocracy
you put between the RDBMS and the app code, the more places you will
often have to change.

So let's not have bureaucracy. Let's have a well defined interface that acts as a partition rather than a mediator.

The partitioning of the code in the Payroll example is just that, a partitioning. There is no vast bulk of "extra code". The database code in the example is primarily concerned with generating and executing SQL. That code would have to be SOMEWHERE in the application irrespective of whether you use OO or not.

For example, if a new attribute or table is
needed for a given calculation, then likely there will be two 2 units
that need changing: the SQL along with the SQL wrapper's interface, and
the app code that uses it. However, if the SQL was together, then only
one unit needs changing.

Let me translate this into procedural-speak. If a new attribute or table is needed for a given calculation, then likely there will be two places in the code that need changing. The SQL, along with the code that moves the query results into convenient variables, and the app code that uses those variables.

We can make sure that only one unit is changed by cramming all our code into a single unit. Clearly that's not ideal. We have to have some kind of partitioning scheme. The scheme I chose in the book was to separate code that knows about database implementation details from business rules.

Thus, wrapping is more effort: one has to make
2 hops instead of one.

Wrapping is not more effort because it always needs to be done one way or another. Either we pull the data out of queries an into objects, or we pull the data into convenient variables.

Swapping DB vendors is fairly rare.

Swapping DB vendors is a TEST, not a goal. You know you have isolated the business rules from the DB implementation details if you can swap the DB.

We can argue about whether or not it is wise to separate business rules from the DB implementation. In many applications this might not be the right choice. For many applications it is. There are many reasons why such a separation might be beneficial.

1. Unit tests don't need the DB. This is actually a very big deal for some applications.

2. DB code makes business rule code hard to read. This may or may not be true depending on the language and platform you are using.

3. Changes to the database and schema need to be isolated from the business rules. For example, the business rule code need not be affected by a change from embedded SQL to stored procedures.

4. Different Expertise. The folks doing dataase queries may not be the same folks who are writing the business rules. It would be nice if they could play in different sandboxes.

5. Database tools sometimes require preprocessing or postprocessing of the code. It would be nice if the business rule code were not involved in such machinations.

etc. etc.

I like to spend my time on real work, not red tape.

I agree. If maintaining the separation between Business Rules and Database turns into a lot of red tape, then it should be eliminated. I have certainly seen such red-tape implementations, and have gotten rid of them for that reason. Most of the time that red-tape has more to do with convoluted layering schemes and "clever" code generation techniques, than with simple partitioning. The amount of red-tape in a simple partitioning model is very limited.

I also would like to see your comments on taxonomy issues.

I thought your comments were very intresting. There is indeed an argument to be made for allowing every employee to enjoy every payment scheme. Why shouldn't salaried employees be able to get commissions, or submit overtime hours? If that were a requirement, then some reworking of the payroll example would be in order.

What would we need to do? We'd simply put a collection of PayClassification objects into each employee, and use the Composite pattern to treat them as a single PayClassification. Within the business rules themselves this would require no changes to any of the existing modules. The CompositePayClassification would need to be added. The individual transaction objects would then create and modify employees with the Composite object instead of with the individuals.

This is simple, and keeps the code nicely partitioned. Changes to salary policy do not affect changes to hourly policy, etc.

So, in fact, the "taxonomy" does not get in the way, and actually facilitates the new mode of operation while keeping the code nicely separated.


--
Robert C. Martin (Uncle Bob)  | email: unclebob@xxxxxxxxxxxxxxxx
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |



.

Relevant Pages

  • Re: Critique of Robert C. Martins "Agile Principles, Patterns, and Practices"
    ... wrap the SQL. ... forget about the SQL and Schema while dealing with the business rules ... The partitioning of the code in the Payroll example is just that, ... such a separation might be beneficial. ...
    (comp.object)
  • Re: Sql / Dot Net General Discussion
    ... have some sql skills but they are limited. ... to enforce, in a database, a large number of business rules that are unrelated ...
    (microsoft.public.dotnet.general)
  • Re: Question on permissions for base tables of Materialized view and mv logs
    ... PCT not supported with this type of partitioning ... SQL> create materialized view dis_eul.dis_mv ... NOCACHE ... NOPARALLEL ...
    (comp.databases.oracle.server)
  • Re: Validating Surrogate Keys
    ... the importance of partitioning -- two resources. ... There is an entire chapter in the SQL Server 2000 Resource Kit on this ... SQL BI Product Unit ... Assuming that have an index built on the dimension tables using ...
    (microsoft.public.sqlserver.datawarehouse)
  • Re: Partition???
    ... SQL Server 2000 Resource Kit (if you can't get it from your local ... The SQL RK is one of the resource kits that TechNet ... The SQL RK has an entire chapter on AS partitioning. ... What is Partition in Analysis Service? ...
    (microsoft.public.sqlserver.olap)