locked
domain model vs service manager model RRS feed

  • Question

  • Hi All,


    I fairly new to those architencture enterprise pattern, and I woul like to ask you whether you know of any good source than comparte the domain model with a service manager model.

    For domain model I mean a collectioin of object that implement bacis properties, business logic and behaviour.

    For service manager model I mean a model in which the different entities have basic properties, are interrelated to each other, but all the business logic and CRUD methods are delegated to a ManagerClass.

    Ex

    Domain object

    Person
       name
       surname
       FindByID(ID)
       update()
       load()
       insert()

    While in the service model

    Person 
        name
        surname


    PersonManager
       Save(Person)
       Update(Person)
       Delete(Peson)


    What are the strengh of the two different approach. How do they differ in practice?
    Which one would you prefer?

    Thanks

    Pierpaolo



    Friday, August 14, 2009 2:03 PM

Answers

  • I have seen Service Manager Model is prefered over Domain model due to following reasons

    1) Service Manager model as you have articulated produces light weight entity objects (Person) which can be passed across tiers, this is especially useful in multi tier, service oriented applications where data traverse as light weight entity objects.

    Embedding method signatures with the object as done in Domain Object model are designs suited in single tier or client server apps.

    2) The PersonManger like Class can easily host additional methods like GetPersonAddress(), GetPersonsStayingInSpecificCountry( string Country Id), etc...
    With Domain model it becomes tricky to define containership for methods which are intersecting entities and one usually ends up creating Manager kind of classes.

    3) If you have methods like Insert(), Update(), Delete() in the Person class, you are combining business logic with entity classes. Usually Entity classes and Business logic classes (business rules, data validation , database operation) are seperated into different projects so that you can easily provide stubs to client tier apps., without disclosing business logic. Business logic changes with changing business conditions/rules as against attributes of the objects hence keep them seperate.

    hope this helps. please mark answered if it helps.
    Regards
    Sudhanshu

    • Marked as answer by arguros Thursday, August 27, 2009 1:00 PM
    • Unmarked as answer by arguros Thursday, August 27, 2009 1:00 PM
    • Marked as answer by arguros Thursday, August 27, 2009 1:00 PM
    Thursday, August 27, 2009 10:32 AM

All replies

  • I would highly recommend "Expert C# Business Objects" or "Expert VB 2005 Business Objects" by Rocky Lhodka.

    It covers these issues is GREAT detail with lots of examples.

    Hope this helps.
    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Friday, August 14, 2009 3:50 PM
  • Hi,

    I had a look to the book. To be honest I did not find any comparison between whether It would be better to put all the business logic in the business entity or delegate it to the services manager.
    In addition is a bit too advanced for my level.
    Can you reccomend any other easier source?

    Thanks
    Saturday, August 15, 2009 7:11 AM
  • I have seen Service Manager Model is prefered over Domain model due to following reasons

    1) Service Manager model as you have articulated produces light weight entity objects (Person) which can be passed across tiers, this is especially useful in multi tier, service oriented applications where data traverse as light weight entity objects.

    Embedding method signatures with the object as done in Domain Object model are designs suited in single tier or client server apps.

    2) The PersonManger like Class can easily host additional methods like GetPersonAddress(), GetPersonsStayingInSpecificCountry( string Country Id), etc...
    With Domain model it becomes tricky to define containership for methods which are intersecting entities and one usually ends up creating Manager kind of classes.

    3) If you have methods like Insert(), Update(), Delete() in the Person class, you are combining business logic with entity classes. Usually Entity classes and Business logic classes (business rules, data validation , database operation) are seperated into different projects so that you can easily provide stubs to client tier apps., without disclosing business logic. Business logic changes with changing business conditions/rules as against attributes of the objects hence keep them seperate.

    hope this helps. please mark answered if it helps.
    Regards
    Sudhanshu

    • Marked as answer by arguros Thursday, August 27, 2009 1:00 PM
    • Unmarked as answer by arguros Thursday, August 27, 2009 1:00 PM
    • Marked as answer by arguros Thursday, August 27, 2009 1:00 PM
    Thursday, August 27, 2009 10:32 AM
  • Great points Sudhanshu Hate.  I would also like to add to point #1 that if you're using an ORM like NHibernate or EF then it fits perfectly with the Service Manager model, since you already have your entities, dtos, or whatever else you want to call them :)
    Thursday, August 27, 2009 6:10 PM