So I was first introduced to the idea of a model when I learned WPF. The MVVM concept of a model seems to be more aligned to general 'business logic' encased in a class/set of classes. When I look at MVC though, the model seems to be lightweight-classes that are "passed" to and from the user via forms. Is this assessment correct, or are there situations where a model is something heavier (does more than just hold and validate data input from the user).
You can use Models (classes) as data container (which i usually do) , look at anemic domain model (http://en.wikipedia.org/wiki/Anemic_domain_model), then you can implement business layer, service, data layer independently.
Or you can implement them within your model, which some folks wants to do that due to encapsulation, and several design priciples.
Look into domain driven design as well. (http://en.wikipedia.org/wiki/Domain-driven_design)
Well in MVC or another similar Design Pattern you have defined 3 separate layers of your application. The model with the logic of your objects, the view for showing and getting information from the user, and then a controller witch does the interaction and exchanges between the 2.
MVC is more used for web apps and MVVM with WPF. The reason is that you with WPF can do the databinding of the objects in your View with the one in the ViewModel.
For example a Twiter app: You can do have a model (tweetItem) with all the properties of a Tweet, a ViewModel that gets and stores the tweets in an collection and view that has a list, for showing them, binded to that collection.
There for MVVM or MVC only impact in your app is on how the code is organized.
Related
I am working on understanding MVVM better, and from trusty Wikipedia (and lots of other research), I have gathered that the ViewModel holds presentation logic and the Model holds the business logic.
MVVM Pattern (Image courtersy of Wikipedia)
My question is, how is there a separation of concerns between logic and data when the Model is holding the business logic? Why is this a good pattern and why would I want to use it instead of using MVC where the Controller handles business and presentation logic (if I understand it correctly)? (I am using WPF, which based on my research, mainly uses MVVM and rarely uses MVC, and I still don't understand why).
Separating presentation logic from business logic allows you to change business logic without directly affecting presentation logic.
For example, if you have a RESTful web API that retrieves some data a view should render, the ViewModel should not be directly handling the HTTP operation or any translation of the incoming data. The ViewModel should ask a (separated) service class to retrieve that data and then the ViewModel can choose how to present that data, such as by pagination, sorting, filtering, and so on. You may choose to paginate at the web API level instead, but that's an implementation detail. In the event that your API contract changes, you can change the web API service without affecting the presentation logic: separation of concerns.
Let's get some things straight:
MVC = Model View Controller
MVVM = Model View ViewModel
With MVC, the controller controls the data and the business logic, the model stores the data temporarily, and the View can read the data from the model. In this model, the View handles the presentation logic. In C#, you can use Razor Pages (.cshtml) to dynamically insert values into the view.
MVVM is very similar. The Model is responsible for holding the data and business logic, the View Model holds the data temporarily, and the View controls the presentation logic. The main difference is the physical separation in your code.
With MVC, each step is separated into its own file. With MVVM, usually two or more steps are combined together into one file. This can be advantageous because it keeps you from having controllers that are hundreds or thousands of lines long if you have lots of pages. I personally still like MVC, because it keeps everything separate instead of combining it together.
I have developed a WPF-application. I have a mainwindow which inherit from Window, a tabcontrol and many tabitems in this tabcontrol which inherit from UserControl. Every tabitem has its own cs-file, where I code in C# all the businesslogic, and a XAML-file where the development of the UI is done. I also have a SQL Server with a database which i connect to trough LINQ.
So i have to write about my choice of which controller i use in my application. This is where i get confused, since i havent manually programmed a controller and i thought the ViewModel would behave like a controller in my case. Could this be correct? Can the ViewModel behave like a controller?
A controller can send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document). It can also send commands to the model to update the model's state (e.g., editing a document). Model_View_Controller
The viewmodel is a “model of the view” meaning it is an abstraction of the view that also serves in mediating between the view and the model which is the target of the view data bindings. It could be seen as a specialized aspect of what would be a controller (in the MVC pattern) that acts as a converter that changes model information into view information and passes commands from the view into the model. The view model exposes public properties, commands, and abstractions. Model_View_ViewModel
The introduction of MVVMC (MVC + MVVM) is nessesary in cases you would like to drive many similar pairs of View-ViewModel (use cases). You can then introduce controllers. Model_View_ViewModel_Controller
In the simplest case, have the ViewModel implement the "controller" logic. For large applications, I sometimes use an MVVMC pattern which uses a separate controller class. There has been a lot of recent support on the blogosphere for using MVVMC over MVVM.
MVVM is dead, long live MVVMC!
MVMMC – MVVM grows a Controller
I have a WPF application that looks something like this:
The viewmodel wraps the model and exposes any attributes relevant to the view via INotifyChanged. The view is also bound to several ICommand objects that handle certain behavior triggered by the view. I have an external ICommand who's sole purpose is to save the model to a database.
Everything I've read indicates that neither the view or the viewmodel should have a reference to the repository. This is the reason for Command 3 which is outside of the viewmodel.
My question is twofold. First, is this a reasonable architecture, and second, what is a good way to get the model instance over to command 3 so it can be put in the repository?
I, personally, see no problem with having the ViewModel have a reference to the repository. Trying to avoid this will cause unnecessary complications.
In MVVM, the ViewModel is typically the "glue" layer that sits above your Model - and the Repository is part of the Model (it's part of the domain specific data/logic). My blog series on MVVM shows a good image of how I personally think about this:
Letting the VM work with the Repository directly by putting Command 3 into the VM would likely be cleaner than trying to separate it out.
The View Model should communicate to the Business Layer (Domain Objects + Domain Services) and not the repository directly. Even further, this communication should be done via Commands.
So you have:
View -> View Model -> Command -> Domain Object / Domain Service -> Repository
Unless you are developing a really simple CRUD application ...
I've done a couple of projects in ASP.NET MVC and there is a topic that I haven't really seen covered anywhere. I wanted to get some other peoples' opinions on this.
What are some best practices for designing models? I've taken two approaches in the past: Should models represent distinct entities, or should you have domain specific (sub-domain specific? view specific?) models? The difference really being models representing distinct entities are used in more than one view where as the domain specific models are tied to specific views.
Consider the following: I have a User entity in my application. Should I have a single UserModel that I use in the Register view, the Show view, the Index view, etc., or would it be preferred to have a RegisterUserModel, a ShowUserModel, a ListUserModel, etc.?
I've used both patterns before. The up side of the domain specific models is that any validation logic applied via attributes can be different between views. The down side is you violate DRY and your models get pretty hairy -- even if you separate them in to namespaces. Conversely, using the single model-to-entity pattern leads to overly generic validation data (usually with regard to error messages) but you have a nice, tight model layer and converting between models and entities is a lot easier (less code).
What approach does SO prefer? Or is there an approach that I'm not even considering?
I like to create my data models and then create specific view models as I need them.
The Case for ViewModel
The ViewModel Pattern
When I think of domain models, I think about business logic as well. I try to keep the M in MVC to refer to the models that assist in the presentation aspect of the application, and not the entities (domain objects) that represent my real-world objects.
Model and View shuld be a pair. Building huge Model classes and huge Views is not good idea. In my opinion in your view-Model you should represent only needed part of your business logic. For example. When you'r creating Registration form make your Model and View that simple as it can be possible - Create RegisterUserModel.cs and RegisterUserView.aspx. Do not pass there whole User object. Make it light, don't break Single Responibility Principle.
I have seen lots of tutorials and examples using Model-View UI design patterns, and they all implement them pretty differently, especially the Model part. In some examples Model is data (actual object representation of some DB) in some it's data access layer (like repository pattern) in some it's service layer...
If someone tells you he is using MV* pattern in his app, what will it tell you about app design? Does it maintain in-memory representation of database in object graph and use it as data source or some data access layer to query data base...
What you will choose as a Model for data oriented smart client app containing mostly Tab Pages with Tables?
The word model is used in, at least, two senses. There is your domain model. Here the sense is how you represent your data. There are many ways to structure your data and also many ways to access it. When we talk about the model in this sense we're not particularly concerned with how you are accessing the structures that make it up, i.e., the data access or persistence layer, although you may also hear people speak of the model of persistence. By this, people mean the particular philosophy that the persistence implementation uses, such as ActiveRecord or Repository. You might also hear these referred to as patterns.
Finally, the word model has a very specific meaning in MVC, MVP, and MVVM in the context of a view. In that context it means that particular data object associated with a view, the view model. This could be one of your domain objects, but more typically it is a view-specific object that encapsulates data from one or more domain objects along with ancillary data such as user data that is used by a particular view.
For your application, choose the persistence model that best suits your development environment and language -- LINQ to SQL, LINQ to Entities, nHibernate, Castle ActiveRecord, etc. in the MS world Create view-specific models (classes) for each of your views that hold the data needed by that view. Use your controllers to query your domain model to extract the information needed by the view and map that onto the view model.
If someone says, he is using MV* pattern, it means the application is split into several parts, acting without a direct reference to a specific type, it doesn't say anything about the actual implementation. MVVM means, you have a Model, a ViewModel and View part, that's all.
The model is your data storage. This doesn't say anything of the implementation of it, it can be anything, depending on the task at hand. However, it should be accessed using interfaces, so you can quickly exchange the implementation. That, in a sense, is the whole point of the MVVM pattern - decoupling of the three tiers via interfaces.
Your description sounds alot like my project at the moment - I use sqlite as backing storage with Entity Framework as ORM. However, I also use T4 to generate Dto objects which then get mapped via automapper in the ViewModel, as those only need the data, not the persistance.
The model typically refers to the data layer, but as I discovered, in MVC this can be a little msleading when implementing an ntier approach. The reason for this is that the model is not contained in it's own assembly.
Here is some of very useful feedback I got to a similar question Confussion over MVC and entity model
A model can be considered as data container that facilitates rendering presentation component and/or persisting data to/from data source (i.e. database etc). Besides the data container elements, a model may or may not contain behavior, depending on design context of corresponding architecture.
While the term “Model” is frequently discussed and used in Model-View-Controller pattern context, it is one of most important consideration in current world of software architecture
You may want to look the following article where few popular and new design patterns that are related to presentation component and model are described.