locked
Client side composition or server side composition? RRS feed

  • Question

  • Several threads in this forum are about the mismatch between the real life database schema's with it's normalized data, the remote client that needs to visualize the aggregated view and data consistency. The underlying question in my opinion is: where do we aggregate the data? This raises the question: how do we expose data in the domain services?

    Some options:

    1) let the domain services expose views of your domain objects (the domain service entity is not a 1:1 map to your internal entities). Consequence: the number of domain services will explode.

    2) kind of expose your internal domain model and cut the object hierarchy at logical places server side. Make explicit calls in the client to load related data. This works fine with the ViewModel-pattern which will act as a facade and is able to reconstruct the data aggregation.

    3) like 2) and chain domain contexts on the client and make use of the implicit loading capability of RIA. You have no idea how many service calls will be made.

    4) is there another option?

    2) & 3) require exposing of foreign key properties, so the client is able to reconstruct object hierarchies (the Orderline needs to expose a ProductId, so a Product can be located). Locating associated data is in my opinion also business logic, so I'm not sure if much of this should be located in the UI-tier... On the other hand if the only responsibility of the ViewModel is selecting a specific domain service operation, it should be OK. But we have the issue here that we can't ask the OrderDomainService for the ProductEntity, since there is already a ProductDomainService exposing the ProductEntity.

    Some guidance of the RIA-team is appreciated.

    Sunday, August 16, 2009 4:40 AM

Answers

  • well my own two cents is there is no one single answer. It Depends.

    for example if i am doing an order entry module for a basic cs rep to enter orders then i am going to make what they get as simple as possible with the actual database layout abstracted to just the task of enter and update the order. details like how shipto addresses or inventory are stored are not something that task needs to know about.

    but a simple lookup table might almost be a raw dump of that table.

     

    at the other end of things i might have a utility module for use only by a small number of folks who know about the database and they might need raw access to some of the data at times...

    but thats a small set of the users.

    most of the time i would tend to mask the database details.

     

    Sunday, August 16, 2009 9:39 AM