Business layer role in data retrieval - criticisms please


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 6 of 6

Thread: Business layer role in data retrieval - criticisms please

  1. #1
    Jim Guest

    Business layer role in data retrieval - criticisms please

    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



  2. #2
    MarkN Guest

    Re: Business layer role in data retrieval - criticisms please


    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
    >
    >



  3. #3
    Jim Guest

    Re: Business layer role in data retrieval - criticisms please

    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
    > >
    > >

    >




  4. #4
    MarkN Guest

    Re: Business layer role in data retrieval - criticisms please


    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

  5. #5
    Jim Guest

    Re: Business layer role in data retrieval - criticisms please

    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




  6. #6
    MarkN Guest

    Re: Business layer role in data retrieval - criticisms please


    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.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center