16

I have following layers in my solution:

  1. App.Domain
  2. App.Service
  3. App.Core (maybe you call this one App.DataLayer)
  4. App.Web

Software design pattern is not my question, I have following Model in Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

I want to use this model on the view (for example home page) AND I want to use Id, Name & Value, so if I want to create ViewModel, I'll add following:

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

So, is that good idea? or just use Foo instead of FooViewModel?

Brian Tompsett - 汤莱恩
  • 357
Mehdi Dehghani
  • 296

3 Answers3

20

This may look like a violation of the DRY rule initially, but I'd argue that "similar, and even identical, code" isn't necessarily "repetition" if it does something different or is able to change independently. And in the case of view models, the code is defining what the "client" sees, not necessarily the entities and operations the business talks about. So, you're often revealing models to the client or interface that are sort of "incidentally identical." You may change either the business rules and terms or the end user terminology independently of each other.

So, I'd turn the question back on you. If the domain changes, is it acceptable for the "version 1" clients to continue using the old interfaces? Will you ever reveal terms or operations in the interface that aren't part of the "core business rules?" And vice versa?

Those sort of questions in mind, if your view's "function" is strictly to reveal the underlying domain model, yes, this seems like it violates the DRY rule.

Also bear in mind, exposing a view that changes more naturally with model changes can also be accomplished in some languages with member attributes and reflection. (Or with less repetition through other feats of cleverness... But, "cleverness" often fails to justify the repetition it spares you.)

svidgen
  • 15,252
2

I would have a view model that contained just one property, a Foo instance. That way, you are not violating DRY according to any definition of it, if Foo changes, your view model automatically sees the change, and you leave yourself free of a direct tie of the view model to the model.

If tomorrow there is a need for the view to show something else as well as the Foo, you can just add a new property, and your view model's intent will still be clear, it contains a Foo and something else, you won't have a mixture of properties from Foo with unrelated other properties.

I wouldn't think of your view model as a FooViewModel, I would think of it in terms of what the view is supposed to display. If it just displays one Foo, then the view model contains one property, a Foo.

Not sure if I explained that clearly. If not, let me know and I'll try and reword it when I'm awake!

Avrohom Yisroel
  • 1,027
-2

I would say using FooViewModel in this way violates the DRY principal. When you need to make a change to Foo you also have to make a change to FooViewModel. I think you would be better served simply using Foo as the model for your view. I would consider a view model if you need to display things from Foo and something other things. For example, say you need to render some information from Foo and also from Bar.

zero_dev
  • 105