简体   繁体   中英

Understanding Model & ViewModel in WebView/WinForm in MVP/MVC

I am trying to understand and implement different UI patterns in .NET to see the pros and cons and where they suite best.

I understand the main concept but I was creating an app and a question appeared.

Say we have a class Customer , which represents the core Information of a customer.

public class Customer
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Address { get; set; }
        public string City { get; set; }
        public string Country { get; set; }
        public string PostalCode { get; set; }
        public string PhoneNumber { get; set; }
    }

Now, if I create a WebView or WebForm to show all customers I can use this class to set as source fe to a DGV, being able to show all properties above.

But then I want to show for example a View/Form with the Revenue history of each customer.

So there is a class CustomerRevenue like

public class CustomerRevenue
    {
        public Revenue ActualYearExpectedRevenue { get; set; }
        public IList<Revenue> RevenuePerYearList { get; set; }
        public decimal ActualYearProjectedRevenue => CalculateYearProyection();

        public decimal CalculateYearProyection(int year)
        {
            var daysInYear = DateTime.IsLeapYear(year) ? 365 : 366;
            var actualYearRevenue = RevenuePerYearList.SingleOrDefault(x => x.Year == year);
            var dayNumber = DateTime.Now.DayOfYear;
            var projection =  ((actualYearRevenue.Amount * daysInYear) / dayNumber);
            return projection;
        }
    }

Here, to set RevenuePerYearList we need some time, since let's say we sell a lot and have a huge list of sells with huge lists of articles, so the calculation needs some time.

So now my question:

Should I then have "concrete" classes for each view/model with the data I want to show, ie here I would have apart of Customer class, say a CustomerRevenueModel

public class CustomerRevenueModel
    {
        private readonly CustomerRevenue _customerRevenue = new CustomerRevenue();
        public int Id { get; set; }
        public string Name { get; set; }
        public string Address { get; set; }
        public string City { get; set; }
        public string Country { get; set; }
        public string PostalCode { get; set; }

        public CustomerRevenue CustomerRevenue
        {
            get { return _customerRevenue; }
        }
    }
}

which has (maybe) different properties, so I need to load this "heavy" properties when needed

or

should I stay with only one class (I mean, a customer always has a revenue) and leave the properties "empty"?

The first option makes me have a lot of classes, one for each view/form I want to show data for (maybe being able to reuse some models in various views/forms) but keeps all clean and in a valid state. And also each class can have it's own logic (domain logic - DDD)

The second option is less classes, less code, but some way I end having a huge (God) class, with all the properties a Customer has and all it's logic (methods). I load only the ones I need, but this appears really bad to me.

The third option is to have the big class with all properties and methods as my (domain)model, and create a "ViewModel" (which contains no methods, only props) each time I need to show sth. like above , using it as source for my GridView. This is the solution with more classes and code (big class + ViewModels + (maybe) DTOs), but also the more organized and SOLID design to my eyes... Here the use of a Mapper like AutoMapper would really help, mapping between objects

But this is the part I'm confused about...

  • Are these "ViewModels" a bad pattern using MVC or MVP?

  • Are this the same as the VM in MVVM? Which I Think not, since I've understood VM in MVVM like a "template", but what I talk about appears to me more like DAOs??

  • Or they don't have nothing to do, are just DAOs

I think I am a bit confused about all the different meanings of Model, ViewModel etc, in the different design patterns.

I am hardly trying to understand right MVC,MVP,MVVM and DDD and I think sometimes I am mixing terms...?

First, try to not "mix" things from different patterns, ViewModels are for MVVM, and you NEED ViewModels if you want to implement MVVM (ASP.Net MVC uses something called ViewModels, but it is not the same than the ViewModels in MVVM design pattern)

The ViewModel is like a model for the View. The ViewModel work is to "convert" the Model(s) to something the View can understand.

You can have one o more models (or none) and use it in the ViewModel, you have a ViewModel for each View.

In your example (a datagridview) you can have a model that will represent the data in a datagridview, a DTO if you want, and you can have a property in the ViewModel, a List and you will fill with data loaded from the database. In the View, you will bind that property (the list) to the dgv datasource.

Think that the ViewModel is something like the code behind of the view, but you are working with properties and commands that will be binded to controla in the view.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM