If I have a Viewmodel designed to serve a purpose for a view -
Is it a good practice to add bunch of static methods to the viewmodel like
- getting a list of items(viewmodel object) by consuming data from db?
- updating the db using a property in the viewmodel?
I am using .NET MVC and feel like my viewmodels get cluttered with bunch of static functions and update methods.
The main reason behind creating viewmodel for the views was because the views started to contain a lot of functionalities for which info had to be fetched from all over the place. So instead, i decided to create a viewmodel to get the info from one place with one call.
Am I following a good coding pattern here? Or am I shooting in the dark?
Is it a good practice to add bunch of static methods to the viewmodel
No, your viewmodel should simply be a POCO, containing as little (if not zero) business logic. A view models only job is to move data from the controller to the view.
Generally:
The controller should obtain an instance of a model from somewhere
this can be consumed by the view directly or if multiple models needs
combining or extra information (not in a model per se) is required
then a view model can be created.
Ideally the view model should be created outside of the controller
(keeping the controllers job clean), this can be achived simply by
using a factory pattern
If you read the wikipedia page for the MVC pattern. You'll notice it is solely designed for the presentation of data, not business logic:
Model–view–controller (MVC) is a software architectural pattern for
implementing user interfaces.
so really none of the MVC objects (Model, View or controller) should contain business logic. The MVC patterns job is to render data (full stop)
That all said it is common to put simple business logic into the controller. Once sites get more complex, though, this should be avoided, for fear of creating a god object
Am I following a good coding pattern here?
No, it's not a good pattern.
The main reason behind creating viewmodel for the views was because the views started to contain a lot of functionalities for which info had to be fetched from all over the place. So instead, i decided to create a viewmodel to get the info from one place with one call.
Store functionalities or any kind of logic is not the ViewModel's purpose. It should be just a transport mechanism that holds the data transported between the View and the Controller.
Consider move your "funcionalities" to Application, Service or another layer that makes sense for your application's architecture.
Related
Recently, I'm learning MVVM design pattern!
In my way, I write the database function in the model, and let the viewmodel to call the database function in the model, then the viewmodel get database data and set to the viewmodel notfiypropertychanged. This is my way that I currently use!
There are some question confused me about model,
I read many article that told me model just a contain data and not more business logic, and here is my question, if model just a data container and I need to let my viewmodel to call the database then get data and set to the model, I think this way is very strange and the viewmodel code is make heavy in it. Is anybody have another method to do it? Thank you!
The Model:
"model just a contain data and not more business logic"
A model is a class which describe an entity within your domain logic. What is a domain? Starbuck's domain is coffee beverages and employees (among others), Ford's domain is cars, assembly lines, and employees. NYTimes's domain is articles, issues, supply routes, subscribers, etc, etc.
A model contains data AND logic. You can have multiple models to describe your domain.
You can place your data calls in your model, but it's more common to have helper classes, data access layers (DAL), keeping all your database calls in one place, and not spread them around.
The ViewModel:
The viewmodel sits between your domain model and your view. It's a class which expose properties of the model and represents the state of the view. The viewmodel may only exposes a subset of all the properties in the model that the UI needs to display, but it could also add properties of its own, for example; is the user in edit mode? have changes been made that needs saving? etc. The selling point with MVVM is that the UI binds to these properties on the viewmodel which is a mechanism to keep the UI up to date with changes, and this extra layer of abstraction conveniently decouples the view to any logic in your model making it more robust for code changes in either direction and testable. There's more to say on this topic, but I'll leave it to you to read on up it.
There are many good resources and info on the MVVM pattern; from blogs Model-View-ViewModel (MVVM) Explained, to Microsoft The MVVM Pattern and here on SO.
If you prefer videos, Pluralsight have good video tutorials on the MVVM pattern
Practical MVVM and WPF MVVM In Depths. They have a free 30-day trial.
"just a data container"
Such classes that only hold data to be passed around are often called Data Transfer Objects (DTO). It's common to keep them small and return collections of these from fetch database data method calls.
I've done some research in this and also found it quite confusing. First thing I like to point out is that code-patterns are abstract. Meaning that you have loads of different way to implement it / tweak it.
What most people have told me is that in "real-life" applications you usually have layers of services.
One of these services is where you get data from a database.
The Model job (in my opinion) is to give the developer knowledge about the database data and structure. One Model to one database-tabel.
It also helps in checking if the data is correct (Format checking, Type of data and so on) before sending it to the DB.
There isn't a clear answer on how to use model. I've seen loads of different implementations, and they all have been implemented for specific tasks.
Yes it might come out that some ViewModels become heavy-loaded with code and functions to perform, but then it might not be because of the code-pattern. It can be because of poor structure in code. At my work right now I've found a ViewModel that contained over 3000 lines of code (Which is WAY to much). This could easily be seperated into atleast 3 different ViewModels and Views, but as I said, poor code structure causes problem.
One thing I recommend for you to read up on is
IoC - Inversion of Control
DoP - Dependency inversion principle
DI - Dependency Injection
Hope this helps in someway explaining your question.
I read many article that told me model just a contain data and not more business logic
A model may be represented by a service, a database access layer or a business layer so there is nothing wrong with your current approach. The business logic does belong to the model.
But sometimes people tend to refer to a "child" type as a model. For example, if your view model exposes a List<Item> property, the Item class may considered to be a model. Perhaps your confusion comes from this.
This kind of classes (Item) typically implement the INotifyPropertyChanged interface to provide change notifications and are effectively rather just "nested" view models that don't contain any business logic though.
Hope that makes sense.
I've been using MVVM for a while now with WPF. And i've learnt a lot over the course of development (going from never using it, to having a couple of applications developed in it)
However, recently I had some comments directed at the code which made me wonder if i'm doing things the right way. My current setup works (roughly) like this:
Model - Responsible for storing the data, data validation using
IDataErrorInfo and dirty tracking
ViewModel - Responsible for getting the data (from a repository like
pattern) and formatting it for a view's consumption (things like
filtering, ordering) also responsible for command handling from the
view (save, load, filter changes etc)
View - The usual UI stuff
Now it was mentioned to me that i should NEVER have business logic inside the model, and that the model should be as thin as possible, the viewmodel should be responsible for handling things such as data validation and dirty tracking.
I've seen comments and criticism on both sides of this, with people against and for putting logic in the model, What i have yet to see is any actual reasons for these sweeping statements. So id love to know if there is an actual reason i should be refactoring my setup.
Also, given that i do move the logic to the viewmodel, I can see the need for having multiple viewmodels where i currently have a single, for example:
Person - Model
PersonViewModel - Handles the dirty tracking, data validation etc
PersonsViewModel - Handles getting a collection of PersonViewModels,
filtering etc
PersonsView - The UI
This seems a little redundant, but perhaps i'm misunderstanding something. What I'm really looking for is some actual reasons for doing this one way or another, or if this is another argument like the use of code-behind in MVVM (pure opinion with little reasons etc)
High level description of MVVM:
View: User Interface
Model: Business logic and data (e.g Domain Model+Repositories, or Transaction Script+POCO entities, etc)
ViewModel: Data exposted to view in such form, that is easily consumable from view. Wikipedia's definition says: The view model is an abstraction of the view that exposes public properties and commands.
I like the Practical MVVM Manifesto (archived version) principes: Simplicity, Blendability, Designability, Testability.
This is very high level and abstract description and that's why you may find a lot of variations of MVVM. Whatever mvvm style you choose, keep in mind the responsibilities and principles and you should be ok. Try to avoid complexity. MVVM is not a silverbullet and you cannot cover all scenarios with single design pattern. One mvvm implementation may be suitable for one application but not for another. I, for example, build my mvvm architecture from scratch for each new project to ensure the best fit
When is comes to responsibilities:
Take validation as an example:
validation logic that password and repeat password inputs should be equal is clearly presentation logic and should be present in viewmodel. On the other side, there may be business rule, that password must contain at least one special character. This logic should reside in Model, however you may expose it in viewmodel to be easily consumable from view. It's a business logic, but you may need to present it somehow.
if you have application that only uses webservice to retrieve and store then your model will be probably just the data access components.
Here is couple of resources:
Wikipedia: https://en.wikipedia.org/wiki/Model_View_ViewModel.
MVVM is variation of Martin Fowler's MVP pattern, you may find it useful as well: http://martinfowler.com/eaaDev/PresentationModel.html
MSDN (Pattern and practices): https://msdn.microsoft.com/en-us/library/hh848246.aspx
I like to think of the Model layer as anything that has nothing to do with how the app is hosted (i.e. independent of WPF). It is one or more dlls that represent the business domain and the operations that need to be performed in it. If it would make sense to take theses same dlls and use them in a web application, windows service e.t.c then it is usually a sign that the split between Model and ViewModel is appropriate.
There's no simple answer to your question. The simplest answer is that the model and view model should contain the code that you should unit test. The separation between model and view model is a little less distinct. I like to keep the model as simple as possible and limit it to whatever is exchanged with the server tier. The view model should encapsulate the model, and provide any addition functionality (both business logic and abstract presentation logic) so that you can keep the presentation layer as simple as possible (declarative, in the case of WPF XAML).
I see it this way:
Model - Object that can be passed around. A Common type between different layers for communication.
ViewModel - Specifically created for Views. This should contain UI logic, for example, Data Annotations etc will go here. You might also call your web service methods here (assuming your actual business logic sits in a facade layer, or your database logic sits in a different layer/project) to populate the Views, dropdowns etc. You might end up with multiples of these per view, depending on your design.
View - UI Only.
I am not afraid to put external calls in the ViewModel
My question is in regard to the first "M" in MVVM, the model. I see a ton of variations on how to implement the model. Some are just POCO's with no business logic and no persistence logic, and others contain one or both.
Right now, in our application, we have a decent separation between models, views, and view-models. This is our current solution structure (its a WPF prism application):
Infrastructure
Module A
ViewModels
Views
Module B
ViewModels
Views
Models (shared amongst modules, which is why its in its own class library)
Services
DataAccess (possibly utilizing dapper-dot-net)
Shell (main WPF project)
We now need to figure out how to perform our CRUD against the database and keep our models updated. I like the idea of keeping the models pretty bare-bones and having a "Services" class library that contains our business logic and performs a unit of work pattern against our data access classes. Are there any known issues with keeping the models dumb and ignorant of business logic / data access? Is this pretty uncommon to do in MVVM?
I wonder if I'm limiting myself or making things more complex than they need to be by not placing some logic in the models, for example, loading a model from within its ctor given an argument. As a note, this will be a large application.
Our application will have to persist models to multiple databases. We're using Unity as our dependency injection container for our services. How would you recommend I tell the service which data connection to use? Ctor, per function, etc?
Kinda looking for someone who built a similar structure, and what their experiences were / recommendations are.
In my view, MVVM models just 'represent' the data and should therefore not have any logic, CRUD or otherwise embedded. You already have the Data Access Layer so it is perfectly normal to write your CRUD code there and to use DI to access this CRUD code from your models.
The "beauty" of MVVM is that it is open to interpretation so I'm sure someone else would argue that model IS the data and it can containt CRUD logic...
I have all my CRUD operations in my DAL and am yet to see the downside of that approach...
Currently in my application and using the unit of work pattern and generic repository, all my controllers contain all of the business logic. I'm in the process of putting everything over to use ViewModels instead of the straight Model.
While this is a good idea, now comes a question that can significantly separate my business logic in the controllers. For controllers and ViewModels, which should contain most of the business logic?
I've tried a few ways to get my ViewModels to practically contain all the business logic. However, I do have to have an argument in my ViewModel's constructor that takes a Unit of Work. Is this a good idea?
My code smell tells me it is. However, I am just a little worried how this will be in consistency with controllers that perform actions that do not need ViewModels. Simply put, actions that do not require to pass a Model/ViewModel to a View; this case happens on actions that do redirects to other actions. Which means, my business logic can either stay in that action or I could separate that business logic into a function.
What is the best practice here?
I can't say that my approach is a best practice, but I prefer to put any business logic in a separate "service" layer.
I tend to use the ViewModel to only store the properties required for a specific view. If there are any methods on the ViewModel, they are likely just to retrieve collections related to that view.
I keep my controllers lightweight by trying to limit them to validation and redirection/displaying views as much as possible.
So if I have any complex logic, I'll have a controller action call out to a separate service just to handle that logic. This way the logic is isolated which makes it easier to test since there's no longer a need to create a controller or ViewModel to test it. It's also easier to reuse a service than to pick apart a ViewModel.
Hopefully this helps. Good luck.
For controllers and ViewModels, which should contain most of the business logic?
None of those.
I've tried a few ways to get my ViewModels to practically contain all the business logic. However, I do have to have an argument in my ViewModel's constructor that takes a Unit of Work. Is this a good idea?
imho It's a very bad idea. First of all you are breaking several of the SOLID principles. Bundling all code into the view model makes it hard to test. What if you want to use some of the business logic in another view? Do you duplicate that code?
What is the best practice here?
Let's go back to the MVC pattern first. It's a quite wide definition but knowing it should give you a feeling of what you should place where.
The "Model" in MVC is really everything that is used to pull the data together. It can be webservices, a business layer, repositories etc.
The view is all code that generates the HTML (since we are talking about web).
The controller should be considered to be a glue between the model and the view. Hence it should take the information from the Model and transform it into something usable by the view.
The problem with that structure is that it's quite easy to "leak" layer specific information into the other parts of the pattern. Hence Microsoft introduced ViewModels into their implementation of MVC.
In this way we can remove all rendering logic from the views and put it into the ViewModel. Instead of doing this in your view:
<span>#(model.Age == 0 ? "n/a" : model.Age)</span>
you put that code inside the ViewModel instead and simply call #model.Age. In this way you don't have to duplicate that code in all views that are using your view model.
The answer to your question about the ViewModel is that it should only contain logic which is used to render the information from the "Model" properly.
As for the controller, I would not put any business logic into it either. First of all, it makes it very hard to test your logic. Then you add more responsibilities to it (and by doing so breaking SRP). The only logic that is valid in the controller is to take the information from the ViewModel and transform it into something usable by the "Model" and vice versa.
Hope that answers your question.
Update
I would create a separate project and add classes to it. Then just add a reference from your webproject and call those classes in the controllers.
I would also start using an inversion of control container to get those dependencies created for me automagically.
Autofac can both discover your services for you (zero-configuration) and inject itself into MVC.
To follow the separated interface pattern create the following projects:
YourProject.BusinessLayer <-- Add your classes here
YourProject.BusinessLayer.Specification <-- Add you interfaces that defines your business layer here.
YourProject.Mvc <-- The MVC project.
The "Specification" project can be used to make it easier to test things and to make it easier to switch implementation (might be only a few classes and not necessarily the entire business layer). Read up on "Seperated Interface Pattern"
Model-View-View Model (MVVM) is a design pattern for building user interfaces. Your View Model is a pure-code representation of the data and operations on a UI. Thus it should contain logic related to that UI.
For example:
if you’re implementing a list editor, your view model would be an object holding a list of items, and exposing methods to add and remove items.
From Wikipedia:
ViewModel: the ViewModel is a “Model of the View” meaning it is an
abstraction of the View that also serves in data binding between the
View and the Model. It could be seen as a specialized aspect of what
would be a Controller (in the MVC pattern) that acts as a data
binder/converter that changes Model information into View information
and passes commands from the View into the Model. The ViewModel
exposes public properties, commands, and abstractions. The ViewModel
has been likened to a conceptual state of the data as opposed to the
real state of the data in the Model.[7]
your controller call the UoW to get the data needed to construct your viewmodel.
you may call more than 1 method of your UoW
then you pass all your needed data to your viewmodel constructor. (passing the Uow to de viewmodel sounds like really bad)
If you need some complex 'logic' on your controller calling lot of methods from the UoW, etc, you should consider creating another repository or a business logic only layer that does all the hard work and you call it from your controller like
SomeClass something = Uow.BLGoodName.DoSomeFancyStuff(params ..)
ViewData.model = new ControllerActionViewModel(something);
Return View();
I'm working in a C# project and we are , in order to get some unity across the different parts of our UI, trying to use the MVC pattern. The client is windows form based and I'm trying to create a simple MVC pattern implementation.
It's been more challenging than expected, but I still have some questions regarding the MVC pattern. The problem comes mostly from the n-n relationships between its components: Here is what I've understood, but I'm not sure at all of it. Maybe someone can correct me?
Model: can be shared among different Views. 1-n relationship between Model-View
View: shows the state of the model. only one controller (can be shared among different views?). 1-1 relationship with the Model, 1-1 relationship with the controller
Controller: handles the user actions on the view and updates the model. One controller can be shared among different views, a controller interacts only with one model?
I'm not sure about the two last ones:
Can a view have several controller? Or can a view share a controller with another view? Or is it only a 1:1 relationship?
Can a controller handle several views? can it interact with several models?
Also, I take advantage of this question to ask another MVC related question. I've suppressed all the synchronous calls between the different members of the MVC, making use of the events and delegates. One last call is still synchronous and is actually the most important one: The call between the view and the controller is still synchronous, as I need to know rather the controller has been able to handle the user's action or not. This is very bad as it means that I could block the UI thread (hence the client itself) while the controller is processing or doing some work. How can I avoid this? I can make use of the callback but then how do i know to which event the callback comes from?
PS: I can't change the pattern at this stage, so please avoid answers of type "use MVP or MVVC, etc ;)
Thanks!
Model, View, and Controller are conceptual layers, not individual objects, so honestly it doesn't make a whole lot of sense to be thinking of them in terms of multiplicities. Nevertheless, I can try to approximate an answer for you.
A Controller returns a single result for a single action; that result may be an actual view or it may be something else. However, the Controller doesn't really actually have any interaction with the view; all it does is provide one or two pieces of information in its result: The name of the view that should be used and (optionally) the model used to populate. It's up to the View Engine to actually create and bind the view, which is a considerable departure from normal Smart Client UI logic.
A Controller may interact with several different pieces of the Model, or not interact with it at all in some cases; there is no rule for that side of the relationship. In an action result, a Controller has to give back either 0 or 1 instances of a "model", but this may not be the true Domain Model, it could be a View Model.
A View is generally bound to exactly one Model (or View Model), although in some cases a View might simply be content and therefore not bound to anything.
So, in the very crude UMLesque parlance:
Controller:Model = 0..* : 0..*
Controller:View = 0..* : 0..1 (request) or 0..* : 0..* (overall)
View:Model = 0..* : 0..1
This is all specific to ASP.NET MVC. If you were designing your own MVC implementation then obviously you could choose to implement it any way you like. Good luck implementing MVC in WinForms, though; Forms don't behave like Views at all, even patterns like MVP/MVVM are quite difficult (though not impossible, c.f. Microsoft's CAB/SCSF) until you move to WPF.
I´ve implemented the MVC pattern in C#. Don´t know very much about theory, or how it should be, or shouldn´t be. I just think that the pattern is the base idea, and then, you can use this idea in many different ways, depending on your own needs. I´ll tell you about my implementation, and hope it helps you.
**The Model**
Your description is pretty clear, so don´t have much more to said. Here is where I define my bussiness objects. I take advantage of this layer to include objects validation rules.
**The Controller**
In addition to handle the user actions and update the view, I have a Unit Of Work for each controller. I check that the objects in the view pass the validations (defined in the model layer) before commit changes in the Unit Of Work.
In my case, one controller can manage many models, and I like to have only one view in each controller.
Like a suggestion, I´d like to use my Framework with diferent UI, so I have an abstract implementation of Controller, and then I have specific controller implementations for different interfaces (WebForms, WinForms, ...).
**The Views**
In your case, we could call them, simply, the forms, the UI, ... I like to organize my desktop applications as if they were web applications, using tabs. One tab represents one controller, and so on, one view, and one or more models.
In conclussion, and in my case:
n models - 1 controller
1 controller - 1 view
--
n models - 1 view
You're probably over-thinking and over-formalizing it a bit.
Here's how I look at it:
Model: This is the actual thing that does real work.
Controller: This is the thing that sends inputs into the model, so it will do work.
View: This displays the results.
That's it. The easiest analogy to use is a console application - the app is the model, STDIN is the controller, and STDOUT is the view.
Extending that analogy, many GUI apps are built on top of command-line apps by attaching to STDIN/STDOUT. In that case, the things sending data to STDIN are the controller, the things taking data from STDOUT and putting on the window are the View, and the console app is still the model.
It's CS 101 again - input, processing, output. It's only trickier for a GUI app because the input and output are typically on the same window.
You (obviously) don't need to actually have a console app to do this - the separations can be done even in a single process. All the other weird wiring stuff that takes place is just whatever is needed to get this relationship between the parts to work. But the wiring isn't the important bit - the important bit is the separation of responsibilities and logical organization of the code.
So, whether 1 view must map to 1 controller, or any other orthognality issues are secondary. In fact, you should probably just do whatever your problem domain requires, but I'd (as typical) argue against over-eager generalization of code - IOW, don't mush things together that aren't really the same.