Re: Mixing OO and DB
Date: Mon, 3 Mar 2008 19:14:39 -0600
Message-ID: <2008030319143917709-unclebob_at_objectmentorcom>
On 2008-03-02 13:19:34 -0600, frebe <frebe73_at_gmail.com> said:
> On 2 Mar, 19:47, Robert Martin <uncle..._at_objectmentor.com> wrote:
>> On 2008-02-28 10:36:03 -0600, topmind <topm..._at_technologist.com> said: >> >>> One-usage wrappers are a waste of code in my opinion and just >>> creates tedious red-tape accessor clutter. >> >> Not if they are explanatory. Employee.find("Bob") is a lot easier to >> understand than Select * from Employee_Table where Name = 'Bob';
>
> Only for people not educated in SQL. Understanding what
> "Employee.find("Bob") ", does, is actually impossible without the
> implementation of find() availible.
Now, now, I think that's an impossible position to hold. Software, whether SQL or Java, is about abstraction. Hiding detailed implementation behind simple abstractions is a powerful and useful technique.
>> In any case, once you have the method, you can polymorphically replace it >> with test methods etc.
>
> The SQL statement "Select * from Employee_Table where Name = 'Bob'",
> may be run against virtually any SQL type database, even in-memory
> databases.
True. But Employee.find("Bob") can be run without any database at all.
>> >> ...most apps need to be tested, and the testing independently of >> the DB can be a significant advantage.
>
> If testing without the DB should be interesting at all, it means that
> you don't use the db for application logic.
It means that you don't use the database for *all* application logic. Consider, for example, determining the simplest travel schedule for 100 sales people visiting 500 cities. You wouldn't want to write that algorithm in SQL. And you'd want to test it against many different data regimes. Testing it without the database in place could be useful.
>>> OOP here is a solution looking for a problem. >> >> Not at all. The problem is very simple. Run 10,000 business rule >> tests through your application in under a minute.
>
> Once I read about a TPC (www.tpc.org) made on a laptop (year 2005),
> and I think the result was 8000 transactions per second.
You missed the point. There is no doubt that databases are very fast transaction processors. On the other hand, when you have hundreds of different data scenarios, each requiring a complete (though small) database, it can take a while to set them up, tear them down, and switch between them.
-- Robert C. Martin (Uncle Bob) | email: unclebob_at_objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 |Received on Tue Mar 04 2008 - 02:14:39 CET