Business layer role in data retrieval - criticisms please

[Jim]

Hi, I'm writing a 3 tier product that is set to evolve in functionality over
several years as more modules are developed and optionally integrated. I
therefore need an easily maintainable and manageable design model.

I have a root object in the data layer that deals with all data retrieval
requests and returns typed datasets.

I have a root object in the business layer that does the same.

It seems like a good idea to derive the BL root from the DAL root and
override/add methods to the BL root accordingly.

Does anyone have a good counter argument

Thanks

Jim

[MarkN]

This really isn't enough info to provide a 'counter' argument. Are you trying
to do OO programming? That really will help with evolving functionality.


No matter what, I think I would think not all of this is a good idea. You
should keep the business and data access (not data) logic separate. Also,
to allow moving to new technologies in the future, you should keep the data
access technology out of the business(domain) objects.


As for deriving objects (inheritance ?) more detail is needed. Be careful
with inheritance. People tend to over do it.



"Jim" <jimshort2000@hotmail.com> wrote:
>Hi, I'm writing a 3 tier product that is set to evolve in functionality
over
>several years as more modules are developed and optionally integrated. I
>therefore need an easily maintainable and manageable design model.
>
>I have a root object in the data layer that deals with all data retrieval
>requests and returns typed datasets.
>
>I have a root object in the business layer that does the same.
>
>It seems like a good idea to derive the BL root from the DAL root and
>override/add methods to the BL root accordingly.
>
>Does anyone have a good counter argument
>
>Thanks
>
>Jim
>
>

[Jim]

Thank's for the reply.

Yes, it is more hybrid OO programming. I am looking for deployable code
reuse rather than complete encapsulation.

What I mean is, for every data access scenario that we will come across in
the future, I believe that it will go down to the stored proc level..,.

Say we want a new view on the data.
1 we create an sp to get the data
2 we create a DAL proc to call the sp
3 we create a BL proc to call the DAL sp
4 we call the BL proc

in a rapidly growing system, almost using the dynamically evolving XP
methodology, we can't really afford step 3 if we can help it.

so inheriting some of the DAL functionality into the BL seems like the best
solution, but i am a bit wary of this hence the post.

i guess what you are saying is that we lose the encapsulation of the data
layer by exposing the methods of the data layer to the presentation layer. i
don't think this is so, because we are still providing an interception layer
in the BL by possibly overriding any of the DAL methods in the BL. i think
it is sensible to use data transfer objects between the tiers that mimic the
data model in naming convention (most of the time) and structure, and that
the tiers become a pipeline of logic on the same data, rather than
transformations of the data between data service and business concepts.

in order for the BL to be a complete mapping to the business model, we need
2 structures to maintain. the storage structure and the functionality.
theoretically this is a good thing, i agree, but practically, unless you
have lots of developers, and funds, it is not possible to implement the
application in this way.

generally i think people model until they have a data model, and then auto
generate their DAL and BL skeleton from that. the rest of the UML they have
feeds the developers to flesh out the BL.

is your business model structure very different to your data model
structure?

if you do, is it because your developers code in different tiers? ie you
have db programmers, business analysts, and ui programmers?


"MarkN" <m@n.com> wrote in message news:3d6ca86b@10.1.10.29...
>
> This really isn't enough info to provide a 'counter' argument. Are you
trying
> to do OO programming? That really will help with evolving functionality.
>
>
> No matter what, I think I would think not all of this is a good idea. You
> should keep the business and data access (not data) logic separate. Also,
> to allow moving to new technologies in the future, you should keep the
data
> access technology out of the business(domain) objects.
>
>
> As for deriving objects (inheritance ?) more detail is needed. Be careful
> with inheritance. People tend to over do it.
>
>
>
> "Jim" <jimshort2000@hotmail.com> wrote:
> >Hi, I'm writing a 3 tier product that is set to evolve in functionality
> over
> >several years as more modules are developed and optionally integrated. I
> >therefore need an easily maintainable and manageable design model.
> >
> >I have a root object in the data layer that deals with all data retrieval
> >requests and returns typed datasets.
> >
> >I have a root object in the business layer that does the same.
> >
> >It seems like a good idea to derive the BL root from the DAL root and
> >override/add methods to the BL root accordingly.
> >
> >Does anyone have a good counter argument
> >
> >Thanks
> >
> >Jim
> >
> >
>

[MarkN]

Jim,
Read this. - http://www.javadude.com/articles/

Writing an OO system that separates the 'UI', the domain objects and the
persistance is not that difficult. It make take a little more time but not
that much. If your system will change (and whose doesn't) it is well worth
the added effort. Of course picking the right tools for the job helps too.
If you are going to use a relational db for persistance you will have to
embed business logic in the database - no matter what you do (any [99.9%]
constraint is a business rule). We try to minimize that as much as possible.
Usually ends up being a few triggers and indexes.

If one is starting from scratch, then he/she should create domain (business)
objects. If you start off with data and think of as that then you will have
problems. In reality you cannot separate the data from the logic. They
are no good with out each other. The problem is that most people use the
wrong terms and thus confusion begins (i.e. data layer vs data access layer).
I quit using data access and say persistance instead because the really
reflects what it is.

If the 'business model' is simple then the 'data model' usually reflects
it.

All our programmers do all 'levels' (Some do more of each). And we have
different UIs. We have HTML, Applets, Applications and Systems (no GUI)
accessing our 'business layer' (the same exact layer). We are using an OR
mapping tool so persistance is pretty simple. I don't spend much time anymore
writing SQL. Just custom queries if needed. And we can switch persistance
types pretty easily. Not all our programmers are an the same level so sometimes
'retraining', etc. is needed. We use a modified XP and it doesn't preclude
doing it the way we do it.

I would say data modeling and OO modeling are pretty close. The data model
usually ends up having some logic it. OO just contains all of both. Sometimes
inheritance gets in the way and you have to handle that. Lets say you
have a customer with a name, and a SSN. The SSN must be unique. Is this
a business rule? I would say yes. In a RDBMS you will need to index the
column or put on a trigger to 'ensure data integrity'.

As for exposing the 'data layer' methods - I'm saying do it via interface.
Don't return ADO objects to the 'business layer'. Using the right tools
this is very easy.

Mark

[Jim]

Thanks Mark.

I agree with what you and the dude say.

But...

If you inherited your BL objects from your DAL objects, you would still have
the interception available in the BL by overriding DAL methods - so the data
passing backwards and forwards through the BL to the DAL doesn't need any
coding until a business rule appears that affects it, and then you can
create the override in the method to enforce the business rule.

However, a change in the DAL would require a rebuild of the BL though.

This way, given a datamodel, I can auto gen all the sps, DAL objects and BL
objects for the basic framework.

The exceptions are our links into mail stores and win2k active directory
which are done a little differently, but they still provide the same
interfaces to the upper layers like you mentioned. The internal code however
is very different, and allows for the data to be routed from any
mail/directory service or for us to fallback on our own system in sql
server.

If you are coding in a replicating environment, the situation is very
different.

If you are using sql server replication then there are many business rules
that you need to be enforced at the db level, mainly because they rely on
other records' data to enforce them. ie maximum numbers of records etc.

The only way to maintain the tiers in this scenario is to replicate at the
BL level which means writing a custom replication and conflict resolution
system.

This is because you can have 2 slave servers merging changes into a master,
where the business rules conflict on the master only.

have you come across the same problems ..?

"MarkN" <m@N.com> wrote in message news:3d6e1556$1@10.1.10.29...
>
> Jim,
> Read this. - http://www.javadude.com/articles/
>
> Writing an OO system that separates the 'UI', the domain objects and the
> persistance is not that difficult. It make take a little more time but
not
> that much. If your system will change (and whose doesn't) it is well
worth
> the added effort. Of course picking the right tools for the job helps
too.
> If you are going to use a relational db for persistance you will have to
> embed business logic in the database - no matter what you do (any [99.9%]
> constraint is a business rule). We try to minimize that as much as
possible.
> Usually ends up being a few triggers and indexes.
>
> If one is starting from scratch, then he/she should create domain
(business)
> objects. If you start off with data and think of as that then you will
have
> problems. In reality you cannot separate the data from the logic. They
> are no good with out each other. The problem is that most people use the
> wrong terms and thus confusion begins (i.e. data layer vs data access
layer).
> I quit using data access and say persistance instead because the really
> reflects what it is.
>
> If the 'business model' is simple then the 'data model' usually reflects
> it.
>
> All our programmers do all 'levels' (Some do more of each). And we have
> different UIs. We have HTML, Applets, Applications and Systems (no GUI)
> accessing our 'business layer' (the same exact layer). We are using an OR
> mapping tool so persistance is pretty simple. I don't spend much time
anymore
> writing SQL. Just custom queries if needed. And we can switch
persistance
> types pretty easily. Not all our programmers are an the same level so
sometimes
> 'retraining', etc. is needed. We use a modified XP and it doesn't
preclude
> doing it the way we do it.
>
> I would say data modeling and OO modeling are pretty close. The data
model
> usually ends up having some logic it. OO just contains all of both.
Sometimes
> inheritance gets in the way and you have to handle that. Lets say you
> have a customer with a name, and a SSN. The SSN must be unique. Is this
> a business rule? I would say yes. In a RDBMS you will need to index the
> column or put on a trigger to 'ensure data integrity'.
>
> As for exposing the 'data layer' methods - I'm saying do it via
interface.
> Don't return ADO objects to the 'business layer'. Using the right tools
> this is very easy.
>
> Mark

[MarkN]

Jim,
I guess I'm not exactly clear on what you are saying. I suspect that while
it may work, it may be a wrong use of inheritance. Without examples it is
tough to tell. I can autogen the persistance from an OO designed system
too. I avoid SPs because the performance gain is usually not worth the pain.
I write minimal SQL anymore. If I need performance then I code for it.
Maintainability and readability come first. Tweak for performance. Check
out Martin Fowlers book on Refactoring (http://www.refactoring.com).

I try to hide technologies. For example my 'program' may not know that
it is using a database or a messaging service (ie MSMQ). I hide that from
them. I've done what Scott (Javadude) has done. I had come to the same
conclusion before I read his article (BTW, he is a very smart dude).

Replication is a pain. So is needing to have BL in the DB. DB2 and Oracle
(and others) allow SP's to be written in Java. This can solve alot of issues.
SQL Server doesn't yet allow this type of functionality yet (Ok you can
call a COM object) but they will in the next release. Unfortunately it will
be their proprietary tools. But if your system is all MS, then it ain't
so bad.

Sometimes the solution to the problem may be to change the whole technique
or technology.