Re: OOP/OOD Philosophy

> Now that you mention it, I have seen hierarchical data access built
> directly into a UI with no separation.
> Separation would've come in handy when relational became popular, right?

The problem is that every new generation of data model moves the border
between database logic and "business" logic. For example, before the
relational model we had a hierachical database like this:

customer A
-order 1
-part A
-order 2
-part B
customer B
-order 3
-part B
-order 4
-part A

Now we want to write a function to find every customers ordering part
A. The "busniess" logic might look like this:

customers = Set()
for each customer:
for each order:
for each part:
if (part = 'A'):
customers.add(part)

Then relational databases came, this would not longer be "business"
logic. It would be replaced by
select distinct customerid from order join orderrow on
order.orderid=orderrow.orderid
where partno='A'

Or worse, the old "business" logic would be keept and the relational
database would be traversed as a hierarchial one (this I have seen many
times).

The idea that "business" logic could be separated from database logic
is an illusion. The next generation of data model will probably again
move the border and the "business" logic you write to today will
tomorrow be regarded as low-level data access logic.

> The scenario that I outlined in my previous example is real. I've
> worked with companies that are moving from centralized databases to
> document based storage.
Can you give a more detailed description of the case?

Fredrik Bertilsson
http://butler.sourceforge.net

.

Relevant Pages

  • Need a generic filling form generator.
    ... I need to write different kind of forms that the customer can use to enter ... data and save the data into database. ... (The data access will be hand coded) ... Prev by Date: ...
    (microsoft.public.dotnet.framework.aspnet)
  • Newbie help with OOD/ADO.NET with C#
    ... It has individual forms for the user to look up existing customers' information, add/view comments about the customer, and set/change/delete appointments or follow up dates, with corresponding button clicks, etc. ... I have written a DBTable class where each instance relates to a table in the database. ... So what I'm asking is if im on the right track with this orientation of classes and separating data access from the rest of the code, or if there is a more elegant way. ...
    (comp.object)
  • n-tier design with "adapter" layer - keepin business layer clean...
    ... In my model a Data Adapter is used to load/persist the Business ... Customer c = Adapter.LoadCustomer; ... Basically the Adapter acts as a bridge between Business and Data ... The UI gets nice Business Objects to work with, the Data Access Layer ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Database help
    ... ForeignKey on Contact or Business (or 2 keys if you prefer, ... If you have individuals frome business, you can also add Adress table and ... Having issues designing something in a database. ... The solution I came up with was a customer table having two fields. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Proper OOP Use
    ... I have 3 projects in my solutions like this: one for Data Access, ... BindingList(Of Customer) so I could bind it to a DataGridView ... individual account information shown when the user selects a customer. ... What is the proper way to fill the database? ...
    (microsoft.public.dotnet.languages.vb)