views:

47

answers:

1

Hello all!

I have an asp.net mvc application with three layers: - data layer with entities and repository (nhibernate) pattern - service layer with services (functions), which communicates with data layer. - ui layer with asp.net mvc application, which communicates with service layer.

The problem is that the data in my entities is different that the data in my views. So I am using custom shaped ViewModels. But I don't like the way I am mapping between the service layer and the view models. Everything is happening in the controllers action. I am using AutoMapper but I think that there is too much spaghetti code. Let me give an example:

1.) I am having an user registration process. I have a FirstName, LastName, Email, OpenId inputs which maps to the same properties in the ViewModel. But than I am having to different entities to store this data (one for the user, and one for the openid identity - user can have multiple openid identities). So in my controller action I have a mapping (AutoMapper) between a view model and a user entity and a mapping (AutoMapper) between the view model and an openid entity. After that I save each entity with the service function.

I miss something - like a custom DTO (I don't think that viewmodel should be shared between the service layer and the web layer) which will be passed between the web and service layer.

2.) I have a search functionality in the application. From the controller action I call the service layer which returns me the list of document entities which matches search criteria. But again the problem is that I also want to display category (different entity) for each result. So in the controller action I am looping between the results and add the category info into IDictionary structure in the view model.

I also miss something here - again some DTO which will return list of pairs (new object): document, category.

Is the DTO right pattern? Should I take a look at the DDD? Any related material will be appreciated.

Many thanks!

A: 

I don't think you are missing a layer in your application architecture, but it sounds like you are missing some types (classes).

Should you create more DTOs? No, I don't think this is a good idea. IIRC, the original definition of DTO was to transfer data across process boundaries. WCF Data Contracts are a good example of DTOs. However, since DTOs are simply messages, they don't contain any behavior. If you base you internal API on DTO it will lead to an Anemic Domain model.

You should still seriously consider adding new types to your application to capture your needs. Where should such types go?

That depends. If you can say that the type in question encapsulates a general-purpose concept, it belongs in a Domain Model. If it only exists to support a given (user) interface, it belongs in that layer.

In your second example you need to combine Document and Category, although they are separate entities. Does this combination encapsulate a recurring concept? If so, it belongs in your Domain Model. If not, it belongs in your UI layer.

If in doubt, place the new type in the outer layer (your UI layer). You can move it to your Domain Model with relative ease if it turns out that it is a more general concept than you first imagined. Moving the other way is harder becuase the type may already have polluted the Domain Model, so starting in the outer layer is the safest option.

Mark Seemann
thank you for your answer. I will consider adding new types and not the DTO's (although I will need a couple of DTO's for my wcf services for silverlight client - but that's another story).
rrejc