locked
What should WCF return Dataset, DTO, Domain Entity, XML Or ? in N Tier architecture RRS feed

  • Question

  • First of all I apologize if I am in wrong forum. I have a very basic question on N tier design and lack of better explanations is haunting me for a while. I want to build a N tier application using

     

    Presentation -> Service Layer -> Business Layer->Data Access Layer

    ASP.NET                    WCF                        C#                     ADO.NET

     

    I have two main classes Order , OrderItems. The customer can view the  Order, and either ADD,REMOVE,EDIT Orderitems.

    My question is what type of object I should return from WCF to ASP.NET.

     

    DOMAIN Entity (this is plain C# class not auto generated EF entity)

     

        class Order

        {

            int OrderID;

            ICollection<OrderItem> OrderItems;

        }

     

    DTO

        class OrderDTO

        {

            int OrderID;

            ICollection<OrderItemDTO> OrderItemsDTO;

        }

     

     

     

    Recommended solution on net

    1>DTO -> biggest problem is NO change tracking.

    If I return a OrderDTO from WCF to UI layer, and edit the  collection ” OrderItemsDTO” by adding more item or removing items etc.

     

    2>Now I send the updated “” back to WCF by calling Wcf.Service.UpdateOrder(OrderDTO).

        Question: How will I know what items are ADDED, UPDATED or DELETED.

    I know I can implement “IsDirty” market pattern.

     

    4>Please let me know if there is something wrong fundamentally, and instead of returning

    OrderDTO from WCF, I should have returned Order domain object?

     

    5>Or should I use Typed Datasets to return from, WCF?

    Thursday, July 16, 2009 11:11 PM

All replies

  • like many other design questions, i don't think there's one good answer, it all depends on the scenario...
    the way i see it, one of the reasons for DTO and contracts is to decouple the data entities from the technical implementation to enhance interoperability and integration. this obviously comes with a price, e.g. you are more restricted around the capabilities you gain from the platform (i.e. state management in poco's). it's up to you to balance the influences when you design the architecture to meet the non-functional requirements (e.g. interoperability and integration) with effort and cost.

    from my experience, if you can ensure that all your consumers will be .NET, you gain huge benefits in moving the domain objects (as poco's) using wcf and not using dto's. this technique has significant impacts on supportability for non-.NET consumers, but you gain better services and overall lower cost development cycle. however, if you must support non-.net clients, you'll have to use dto's which expose a much simpler api and you'll have to manage the objects and collections state manually. if that's your scenario, then one tool that can help you is nhibernate which facilitates state management for objects (i think the entity framework also provides similar functionality, but i don't have the experience to recommend it).

    hope this helps.



    Fernando Felman Solution Architect Unique World My blog

    Friday, July 17, 2009 12:18 AM
  • Taatu,

    You are correct, the common opinion is that you should be passing DTOs through the WCF layer. The main thing here is that the WCF is a messaging mechanism and the DTOs are its payload. As such, they only exist to be passed from point-to-point. Some even go so far as to translate the DTOs into a client-side domain model.

    I, personally, would not use any kind of dataset to pass data back and forth. I would be concerned about the size of the messages and the complexity of the dataset. Another issue with them (I've been told) is that if you take the dataset directly from your database, you potentially could be exposing information about your DB schema to the client, which is a no-no in the security world. (Had some older code fail a security audit based on this kind of thing).

    FInally, you could pass Domain Model objects, and a lot of people do. And a lot of people hate that. Dave Morton, one of the MVPs hereabouts, has a very good blog entry about what happened to "a fledgling you developer" who did this and wound up in a lot of trouble. Check it out at: http://blog.davemorton.net/2009/06/why-you-should-never-make-your-business.html

    Based on your description, I would argue for DTOs, but I don't have your boss breathing down my neck to get this done. (I have 3 of my own, thank you very much.)

    Chris
    Chris Snyder, Stumbling through code one day at a time If your question was answered, please mark it.
    Friday, July 17, 2009 12:32 AM
  • Taatu,

    Okay, first of all, a DTO is all about making a course grained call to a number of services, and thus reducing the call overhead.  It has very little to do with change tracking (you're returning data, which assumes that nothing has changed at this point)  You can also view them as close-to-schema models are well, so you break the coupling to the database schema underlying, but that is not really their primary purpose - a domain model could do that by selecting things

    That DTO object could be mapped to Domain Objects in the business layer, in such a way that you have the original copy, and the current copy of the data.  The current copy is kept at the data layer, and when the call comes back you can do a set comparison to create a changeset for the data, or send back deltas of what has changed.  Alternatively if you're not too bothered about re-writing the same data for one changed value, then IsDirty is fine.

    I would suggest with a service call that you use the DTO, as it is course grained, rather than calling many services one after another, and ending up having the overhead associated with doing so.  On the other hand, if your only call to the middle tier code is for orders, and all you want to ever do is call order, then the Order domain object is fine.

    Personally I dislike datasets, simply for the fact that by gaining a quick solution, you lose some control over your objects and how they work.  There are good reasons for using them, but using them as a DTO probably isn't it, as there is a lot of other overhead that you probably don't need associated with datasets.

    I hope this gives you some ideas to go and research a little more.

    If you have any more questions, please ask,

    Martin.

    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Friday, July 17, 2009 9:39 AM
  • Hi,

    4>Please let me know if there is something wrong fundamentally, and instead of returning

    OrderDTO from WCF, I should have returned Order domain object?

    If you return Order that's mean you Business logic cross cutting all layer which mean there is no encapsulation for you BLL, and I don't recommended it.
    5>Or should I use Typed Datasets to return from, WCF?

    The Typed Datasets is strong but it's performance not like the Reader I will not recommend it either except some special cases.

    So the answer is DTO I think this is the good solution.

     

    2>Now I send the updated “” back to WCF by calling Wcf.Service.UpdateOrder(OrderDTO).

        Question: How will I know what items are ADDED, UPDATED or DELETED.

    I know I can implement “IsDirty” market pattern.


    I don't know what you mean by "ISDirty" but I am afraid this my solution which will use a mechanism in the DAL that can all, that's mean I will update the (OrderDTO) and every OrderItemsDTO so any change will send back the DB.


    Thanks


    We are volunteers, if the reply help you mark it as your answer. thanks!!
    http://mohamed-radwan.spaces.live.com/default.aspx
    Sunday, July 19, 2009 7:28 AM
  • Hi,

    Using DTO over Domain objects has its own advantages.
    1) DTOs are ligth weight, just a set of getters and setters unlike Domain objects which is heavy with methods and busines slogic. Therefor, trasfering DTO to clients over the wire gives u edge compared to transfering Domain objects.

    2) DTOs are the best way t go if your clients can be non .net clients
    3) DTOs decouples the business layer

    So I would defintly go for DTOs, you never know how your systems changes in a few years :)
    And about change tracking in DTOs...Entity framework 4 (in beta) allows this with POCO, and your are correct you could use something like a Is Dirty pattern to see if your DTos are dirty.

    Regards,
    Nairooz NIlafdeen
    Monday, July 20, 2009 5:30 AM