locked
Business Layer and ORMs: Rich Vs. Plain objects RRS feed

  • Question

  • I am putting together an Architecture Framework based on nHibernate and Spring.Net, using many of the concepts in the Esposito, Saltarello book. I have read in many forums and articles, that the Business Layer should be composed of Rich Objects (attributes + behavior), but since I'm using an ORM, the Domain Model Objects are plain objects (no behavior) which in some cases I'm reusing as DTOs (to be consumed by the UI). My Business Layer is a collection of helper classes, that most times call the nHibernate Session methods to update the database, taking any of those plain objects as a parameter. They also include some validation methods, but nothing else. These helper classes are consumed by the Service Layer ones.

    Is this an acceptable pattern, or should the Business Objects always include some behavior?

    Thanks in advance for your help!

    Ricardo Villalobos

    Friday, April 24, 2009 8:35 PM

All replies

  • Hi,


    I have some question to you.
    • Domain Model Object are generated by any third tool or written by the developer? 
    • Do you have more control on the methods generated or created by the developer ?
    • When you are sending object , you have calculated the performance the entire application using DTO from UI to database and back from the database to the UI.
    • the architecture that  you have created is very flexible to meet future business needs.

    NOTES:

    • BUSINESS LAYER MEANS HANDLING THE BUSINESS FUNCTIONALITY OF YOUR ENTIRE APPLICATION. HOW YOU DESIGN THE BUSINESS LAYER IS MAINLY DEPENDS ON YOUR ON BUSINESS NEEDS , ARCHITECTURAL REQUIREMENTS, USE CASE REQUIREMENTS , DATA ACCESS LAYER AND THE SQL SERVER DATABASE.
    • DAL LAYER IS MAINLY USED FOR PROCESSING INFORMATION AS PER ACTIONS SEND BY THE USER FROM THE GUI TO THE DAL WHERE BUSSINESS LAYER IS THE INTERMEDIATE LAYER BETWEEN THE UI AND THE DAL LAYER.(IT DIFFERS - A GENERIC APPROACH).

    Regards,
    Phijo Mathew Philip.









    PHIJO MP
    Saturday, April 25, 2009 2:13 PM

  • Hi,


    One more questions

    When you are using the DTO objects , have you considered the performance of the entire application when the user interacting with the UI. Memory utilization.


    Regards,
    Phijo Mathew Philip.

    PHIJO MP
    Saturday, April 25, 2009 2:18 PM
  • I am for the idea of POCO...essentially plain simple business objects.  I use an application service layer for expressing application functionality.  I do tend to put validation concepts into my objects as I feel that that is a purpose of the domain layer...to keep itself clean and appropriate.

    Look up DDD or domain driven design. 

    Specifically take a look at this book (free as PDF): http://www.infoq.com/minibooks/domain-driven-design-quickly

    It will help you to get a good idea of how this should work.  If you follow the DDD concepts you will end up with a very testable framework which is very adept to change.  NHibernate is a good tool for getting you into a POCO / DDD world.  I have tried using Entity Framework but still feel that it is not ready yet.  So lately I have been using LINQ to SQL...which is perfect.  Not as complex to run as NHibernate...not as cumbersome or heavy as Entity Framework.  Simple.

    Andrew Siemer www.andrewsiemer.com blog.andrewsiemer.com www.socialnetworkingin.net
    Tuesday, April 28, 2009 7:01 PM
  • 1) The Domain Model Objects are generated by a tool, based on ActiveWriter.
    2) Yes, the methods exposed by the Service Layer are hand-crafted, based on the UI requirements.
    3) In some cases, I create "Display Objects", which might be a subset of the original DTOs (or BOs in this case), for performance purposes. However, for small applications, I usually can reuse the DTOs with all their attributes.
    4) Based on Spring.net, yes, it is very flexible (using IoC and AOP principles)

    I understand the purpose of the Business Layer, but some texts (like the one I mentioned above) promote the use of rich objects inside of it. I prefer to only use helpers, affecting POCOs. 

    I hope this answers your questions. Thanks for your feedback. 
    Tuesday, May 12, 2009 5:36 PM
  • If you add validation methods to an object, can it still be considered a POCO?

    I am doing the validation in the Business Layer, through helper classes, affecting Plain Objects (only attributes with getters and setters, no behavior).

    Thanks for the link. I definitely follow Domain Driven Design principles in the framework (The BOs are not necessarily a one-to-one relationship to database tables), but I believe that you can still design a Domain Model with POCOs and helpers (instead of rich objects with behavior inside). I guess this is the real question that I wanted to ask in this topic...

    POCOs + Helpers in the Business Layer Vs. Rich Business Objects (Attributes + Behavior)

    Thanks for your feedback
    Tuesday, May 12, 2009 5:43 PM
  • I don't think that it is actually POCO at that point...but it is convenient!  I generally use a service that has my validation for the objects.  An object specific validation service and a generic tools validation service.  However, I like the idea presented in Scott Guthrie's chapter here (http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx) that puts the validation (and a couple of other methods) in the object itself.  When using LINQ to SQL you can have the object do it's own validation directly when LINQ to SQL attempts to save the object.  If the objects validation returns false (or throws an error) you can force LINQ to SQL to not save.  This is very handy!

    You can still wire this up using your validation services but the method must be called on the object itself...which can then call into the validations service to validate itself!

    Entity Framework doesn't provide this tie in...lame.

    Andrew Siemer www.andrewsiemer.com blog.andrewsiemer.com www.socialnetworkingin.net
    Tuesday, May 12, 2009 5:49 PM
  • I can see the benefits of having the validation inside the object itself, but two comments:

    1) How is this going to affect serialization? The Presentation layer consumes these objects through WCF Web Services.

    2) By keeping Validation inside the Business Layer Helpers, we can create "custom" regions that can be altered after deployment (through IoC in spring.net). Therefore, we have the generated validation methods (based on DB rules), plus standard or handcrafted validation methods, plus an optional custom validation before the object is actually persisted (which is injected through spring). One problem of this approach is that any validation from the Presentation Layer requires a round trip to the Middle Tier, but we have solved this by also generating Javascript (or Silverlight) validation methods that can be used on the Presentation Layer directly.

    Thanks again for your feedback
    Tuesday, May 12, 2009 5:57 PM
  • In your case validation in the objects may not be the best approach!

    Andrew Siemer www.andrewsiemer.com blog.andrewsiemer.com www.socialnetworkingin.net
    Tuesday, May 12, 2009 6:01 PM