I have following layers in my solution:App.DomainApp.ServiceApp.Core (maybe you call this one App.DataLayer)App.WebSoftware design pattern is not my question, I have following Model in Domainpublic 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?
Is that good idea to add ViewModel exactly same as Model
asp.net mvc;model
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.)