Hacker News new | ask | show | jobs
by snomad 3058 days ago
General question for any pros on here, when querying for a read only report, is it standard practice to map from a viewModel/dto to a domain model? Seems a little counter productive to me (for reports) as viewModels will typically have extra concepts foreign to the actual domain model (eg pagination)?

Totally get the benefit of DTOs for create / update, but it feels like an unnecessary step in read operations.
3 comments
hudo 3058 days ago
If you don't have to map to DTO, or domain == dto, then its probably an overkill.

But what if you expose domain model to the view, and view changes some property? Are you 100% it will not be saved to db?

If you change one field in a db, do you have to change domain model and UI also?

Important concept is Persistence Ignorance, and how "far" are you willing to go with decoupling application layer from database and domain model. It really depends on your app, and there's no "one correct way of doing this".

link
tuespetre 3058 days ago
I usually end up writing view models for reporting views because it condenses the type and amount data that is actually needed for the view, and (pet peeve) VS/Razor kind of don't work so well together in terms of notifying developers of errors while refactoring unless you actually have all of your views open in tabs in VS.
link
ctrl-j 3058 days ago
> VS/Razor kind of don't work so well together in terms of notifying developers of errors while refactoring unless you actually have all of your views open in tabs in VS.

Two things:

1.) ReSharper full solution analysis should bring those errors up. I wouldn't leave it on all the time, but flipping it on/off occasionally works wonders.

2.) Even without that, turn on the option to compile your views when you build. It's not super graceful (you'll have to fix one error at a time), but at least you won't accidentally ship a broken view!

link
Lord_Zero 3058 days ago
hudo's example is really good.

Something else to consider is that maybe your MVC project is not your ONLY consumer of your application services. Now it makes a lot more sense to decouple things and maintain that extra layer.

Also the ViewModel is tightly bound to the view, if you want to change the view in clever ways that should not change the domain models.

link