Announcement Announcement Module
No announcement yet.
Business-layer vs. model-layer Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Business-layer vs. model-layer

    I would like to start a discussion about the business-layer and its relation within the model-layer.

    There was once a time, I 've thought of seperating those, following the three tier architecture (Presentation, business, implementation), but this is wrong I guess.

    Currently I think the business-layer includes the model-layer, making the model-layer a part of the business-layer.

    The achitecture of my current project looks like this:

    Model: 4 Hibernate persisted object classes

    Plain Business: One CoreModel interface providing access to additional model-related operations, like to create new objects, to delete them (make them transient) or to perform some complex queries. It becomes an mediator for several daos and controls some advanced transaction managements.

    Implementation-Layer: Hibernate related stuff (two classes, Spring hibernate support is just great)

    Daos: Four Dao implementations (are they part of the business or the implementation layer?)

    There is also another interface used for remote access of a complex client application. I also consider this to be part of the business-layer.

    So the question remains: Are my thoughts ok?


    Martin (Kersten)

  • #2
    I prefer to keep the persistence tier / model layer separate from the business layer, both conceptually and practically through separate package, classes, interfaces and a clear separation of concerns. My main motivation for this is to keep persistence implementations decoupled from the business layer so that if I want to move away from Hibernate to SOAP, EJB or JMS calls for one or all of the data sources, I can do it without much work in the business layer.

    I do realize that for many applications this is unnecessary overkill, and sometimes I grow into this separation by first creating a proof-of-concept without all those additional components and layers. However, where I work, our designs eventually have to go in front of an architecture review board and they appreciate the separation of layers to make it easier to scale the apps down the road (we're becoming very SOA-focused as a result of having to deal with lots of apps whose usefulness grew faster than their architecture). As always, it ultimately comes down to a conscious design decision, weighing the tradeoffs.


    • #3
      The model is also resisting in it's own package and it is not aware of the DAO implementations. So the package/modul dependency is like:

      DAO <-- Business Interface ---> Model

      But the question is, where to draw the line and call that thing Business-layer. That's bugging me for ages.


      • #4
        I guess I don't understand. To me, the DAO layer is totally about implementation, whereas the business layer is about service-based aggregation.



        • #5
          The Dao satisfies the needs of the business logic. Sure it is an implementation detail but the requirements are imported from the business layer. So at least the specifications of a DAO are part of the business logic (interface belongs to client principle).

          the DAO layer is totally about implementation, whereas the business layer is about service-based aggregation.
          I guess you refer to the three tier achitecture (Presentation, business, implementation). There is also another architecture possibile: three layer architecture: Presentation layer, business aka domain-layer, data source layer.

          Since I wouldn't like to talk about tiers - they have further requirements like chinese walls - I would like to talk about the three layer architecture.

          I noticed that mearly every project I did, the model, dao and the rest of the domain logic is melting together (clearly seperated within packages of cause). The needs of the domain logic drives the model and the model drives the DAO (vise versa). I guess it is quite difficult to say, where to put new code.


          • #6
            I think I understand what you're getting at, in that business requirements (usually submited in terms of visual and behavioral terms) have a direct influence on app design all the way down to the persistence layer. That's true, and any given layer is meaningless in this respect without its business context, so, you could argue that there is a blur in the distinction between them.

            However, you need to remember where we used to be in terms of application design before layered architectures became popular. Without a clear and operable distinction between the layers, many applications in the past suffered greatly under convoluted and intertwined spaghetti code. I could reference a dozen in-house ASP/COM, PHP and Perl-CGI apps that are still maintained in my area today, and they're very difficult and expensive to work with. Furthermore, the move from one DB technology to another (from MS SQL to Oracle and DB2 in our case) will take a lot of work, and you can pretty much forget about web services for these apps without writing entirely new and segmented code.

            If what you're observing is simply a facet of application construction, then I'll agree, but I'm sold on the idea of layers, both for actual code, but also for sharing a language and a common library of patterns we can use to achieve flexible, scalable apps.

            But as always, your mileage may vary.



            • #7
              I give my point of view in another thread of "Architecture discussion"


              In general terms, I agree with those who think that DAOs don't belong to business layer, although they are invoked surely from there
              Last edited by Rod Johnson; Jan 18th, 2006, 10:12 AM.


              • #8
                In general terms, I agree with those who think that DAOs don't belong to business layer, although they are invoked surely from there
                I guess I have found the spot. Normally the DAO does not implement a given type (-requirement). Therefore there is no interface/abstract definition involved. Since the interface/abstract definition would belong to the client (business-layer) then you can say, the DAO requirements are part of the business layer and the implementation of the DAO (hibernate or what so ever) belongs to the database-layer (implementation tier).

                But to make things clear: You are building a solution using more then one DAO implementation. So you will create something like a DAO interface/abstract type being part of the business layer. Then you will have a logic choosing, which certain DAO implementation has to be choosen. So the question is, is the logic choosing the DAO being part of the business-layer? What do you think?

                For my oppinion, the business-layer does not 'contain' the DAO implemenation for sure. But the requirements about how the DAO looks like/ is used, belongs to the business-layer since the DAO is statisfying the needs raised by the business-layer. Maybe we should drop business-layer and refer to the term of domain-layer. So by using domain-layer it is clear, that the model-layer is part of the domain(-layer).


                • #9
                  How about just say your DAO interfaces define your persistence requirements? And your persistence requirements are driven by your business requirements, and are in direct support of those business requirements. Makes sense to me; as generally multiple persistence requirements (realized by DAO interface methods) are required to execute a single business transaction.


                  • #10
                    i would like to know that how can a business layer freeze an account.


                    • #11
                      This discussion is related to something I have been after for some while. A while back I searched many groups but couldn't find anything.

                      I think it would be great to come up with a default package structure that is a bit of a recommended practices for what types of classes go where and what they should do, something in the order of a maven standard directory layout but for packages. I have pulled down various sample code from different projects and tried to come up with something from that. Clearly there may be different "templates" for small versus large projects, diff reqts etc. but i'd find it very useful. For example:

                      NB: [namespace] = (e.g.[subproject])

                      NB: This is just an example and i'm def Not saying this is correct. Just wondering if anyone knows of something like this or has an interest in constructing one.

                      NB: All packages contain interfaces. If separate dirs for implementations, then subdirectory of 'impl'. If not separate dir interfaces + impls directly in package.
                      • [namespace].service = service classes which includes stateless services, managers, etc. ideally not static so that they can be easily be stubbed.
                        Service classes may contain collections/caches to be able to track the model objects upon which they are working, but if so they should be thread safe if in a multi-threaded env (more and more common these days)
                      • [namespace].model = stateful domain classes. "managed"/operated upon by the service classes. often not beans but if so must be prototype and instantiation managed
                      • [namespace].dao = db abstraction. Here I'd like to detail suggestions - like for non-ORM recommended SimpleJdbcTemplate, declarative txn mgmt, etc...), for ORM.. blah blah. typically injected into services.
                      presentation, etc......

                      NOTE: I use 'service' generically to indicate stateless classes that provide a service and likely take return a result or potentially act upon the object passed in. To me this includes 'Services' and 'Managers' and things like 'Calculators' or anything that fits that description of acting upon objects. I generally use 'Manager' when the class is proactively managing rather than just providing a service. Further, if it acts upon the object rather than returning the "answer" the caller is after (the approach mockists apparently prefer from martin fowler's article , I generally call these Managers rather than Service but that's just a rule I've developed.

                      ALSO.. I watched a video on youtube a few months back from Rod Johnson where he talked about moving more of the business logic out of the services and into the domain objects [at least from my memory] because this is where you can easily get code reuse. This makes sense to me because often the domain/model is the comment component and the services are often application specific and therefore not as likely to be reusable. Having said that I have yet to really utilize this in practice. Ideally we would define in which package(s) the business logic should go, as well as common "rules" or troubles (e.g. try to avoid state here or synchronise it for thread safety or these typically are injected or get injected into others, etc. )

                      Other things that would be interesting to include is ibatis, and where bus logic goes here.

                      hopefully this already exists and someone can point me to it!
                      Last edited by vshankar; Mar 24th, 2010, 11:53 PM. Reason: typeo


                      • #12
                        How to Separate Business layer from persistence layer

                        I am intersted to understand, How this is possible to keep Business layer (Presenatation layer+Business logic layer) and persistence layer apart of each other so that I can make changes to Business layer/ Persistence layer w/o large effect to each other..Can we add any mediation layer to do this..


                        • #13
                          Why not preserving MVC?

                          I prefer thinking about MVC pattern:

                          "Model-view-controller (MVC) is a software architecture pattern that separates the representation of information from the user's interaction with it.[1][2]
                          The model consists of application data, business rules, logic, and functions.

                          So the "model layer" comes to the following package structure, defining two tiers:
                          +-- business
                          +-- persistence


                          • #14
                            Business Layer can contain business service classes which implement well-defined business interfaces. Eg: taking the standard ATM usecase, we can design a ATMService which has service api's like deposit(), withdraw() etc.. (I did not put the input params as I just quoted it for example)
                            These business layer classes will know to work on business domain objects. So in the above example, we can say deposit() knows to work on a Given account and for a given input Money instrument (say Cheque or Cash).

                            The domain objects need not necessarily be the Persistence layer objects, in the sense, for normalization sake our DB model or ORM objects might be a little different from the Domain object, as the ORM objects mostly map directly to table strcutures. The persistence layer will know how to create the Domain Object from the ORM objects or if there is no ORM, it will have the logic of building this object from various result-sets. It will also know how to extract data from domain objects and save to DB using ORM or plain JDBC, whatever the project tech stack is.

                            The business layer does not need to have the detailed logic of persisting the domain data encapsulated in the Domain objects.
                            All it needs to care about is the business logic. In the business logic implementation if there is a step to persist data, it will just call the persistence layer class (which probably will be coded to an interface). The business logic does not need to know how to persist.

                            This way we can draw a clear line between the two layers and using Spring dependency injection techniques can keep the dependencies between these layers configurable.

                            In the context of your question, I perceive the model layer as Persistence layer (not to be confused with the Domain Objects of the business layer).
                            Domain Objects also sometimes act as Data Transfer Objects or Value Objects to carry business data between layers.
                            Last edited by Shiv_S; Feb 25th, 2013, 05:32 PM.