Is Model only Entity Data Model class of my database? Model as simple place where i have my data? Or I can input in Model something more?
The model in MVVM is supposed to be the place for data-centric logic and the data, yes. It can be just the Entity Data Model, or you can add some more logic--that's up to you. The primary point is to seperate any presentation-specific logic from the model and put that in the viewmodel.
Hope that's clear enough
You can do whatever you like...
Typically, though, the "model" in MVVM is considered to be an "external" class (e.g. a generated class from LINQ-to-Entities, say) and so it usually doesn't have much logic.
The model is the core domain logic you are dealing with. It is everything not directly related to a UI view.
An easy way to think of it is the View and ViewModel combined represent what would be a "typical" UI layer without good separation. In MVVM, you split the logical aspects (the ViewModel) from the display logic (the View).
Related
I am implementing a database search algorithm which searches over many collections in a MongoDB and returns optimized results based on the state of the entire database. I have no problems with the implementation, but the nomenclature and how I should structure the file system is bugging me. Where in the model-view-controller pattern should I place read only operations? Is it a service? It has a controller but I hardly think it satisfies the criteria to be a model.
This question is extremely language dependant and the features that exist within that language. I will speak from a PHP point of view.
Search functions should go into the model, the model backs up as a data provider in the MVC pattern. A single central point from which to dish out instances of it self.
Some MVCs implement what is known as factory classes. They are specifically designed to sit outside of the MVCs normal pattern to be able to provide data: http://en.wikipedia.org/wiki/Factory_method_pattern . As someone who has used this pattern I can say it gets complicated and unmanageable very quickly. That is why I prefer to backup the model as a data provider itself, it merely requires class organisation.
Model View Controller architecture is pretty much the equivalent of a three or four tier solution in a client server setup and the same rules apply.
Complex and intensive database functionality lives with the tool that is best suited to the task and is most re-usable and in this case I would argue that the RDBMS would be the best option in the vast majority of RDBMS's as it is the RDBMS that best knows how to manipulate it's data, work out query plans etc...
It could also be argued that the model layer would be the most natural place from a purist coding point of view where you have all your data access in one layer.
It is highly unlikely that it would ever be advantageous to place this sort of functionality in the least re-usable layer i.e. the controller/view
This is of course only my opinion and I suspect you will get many alternative opinions but ( can not for the life of me think that from a performance point of view that yopur logic belongs anywhere other than at the database level
UPDATE
A model is the guardian of all data. if a view or controller wants data, it asks the model for that data. The view or controller shouldn't care about how the data is obtained or where it comes from. It's about separation of concerns. So that leaves the question. Do I place the code to query the database in the model or in the RDBMS?
Well of course you have to have a method in a model for the view or controller to call in the first place so of course you need a model but what goes inside that method and where the actual query SQL lives is up to the designer. The point is, that so long as the query lives at model or database level you are hiding the implementation from the view or controller and are free to change the implementation whenever you wish without having to worry about the potentially many places it is called from.
So model or RDBMS is the answer. The solution chosen depends on the MVC tools you are using and the RDBMS you are using. Also remember that a model does not have to consist of a single method which is what you are implying you may be thinnking from your comment.
I have a quick (hopefully) question on how to implement a composite field using MVVM.
I have 2 examples, one is on the sql end I am storing gps coordinates in the following manner "Latitude,Longitude" for instance "45.55555,-80.00000". the other example is storing feet and inches as a single double field with it being ft.in.
How should I go about this? Should I have two fields and in the model or Viewmodel composite them if the other piece exists? Should I bind them to the same field and somehow validate the sets?
thanks!
In the Model I normally use a structure/layout that is closest/easiest to the source so it can be easily/quickly read and written.
In the ViewModel I aim for a representation of the View to accommodate the bindings.
In general I make the ViewModel responsible for the transformation between the Model and ViewModel.
So whether or not a property of the ViewModel and the Model should have one field or two depends on the requirements of the View and the Source.
I am trying to understand the difference between Model and ViewModel in KO. I understand the conceptual difference, but to me it seems that all Models in KO will become or are candidates to become ViewModels. Ill explain:
Say you have a table with a row of seats, so in your main ViewModel you will initialise and load a collection of objects from a Seat Model into an observable array.
Now you want to hide display seats based on a certain property of seats...this is the point where your model becomes another viewmodel...
So is it right to say that in KO all we have is ViewModels?
Yes. Essentially, anything with a ko.observable is creating a ViewModel. You could create a simple javascript model expressible as nothing but JSON, and wrap it, but the "model" in Knockout's MVVM pattern generally exists only on the server. You get the model data from the server, and you send model data back to the server (remember, you don't send the observables, just their data)
Knockout doesn't really care about where the model comes from, because its primary role is to deal with the databinding between the declarative view (HTML) and the ViewModel (with its View-aware observables).
The MVVM pattern is completed by technology outside of Knockout, since it's a client-side only framework. You could say that it is just the VVM part of the pattern, but that is confusing.
I know that mvvm calls for having a ViewModel class that wraps a Model class, but I'm wondering why it's a better practice to do this rather than just enhancing the Model class directly via partial classes. I get that you might want the Model to be auto-generated from an ORM, but you can still put the ViewModel stuff in another file via a partial class, and doing this avoids the considerable overhead of maintaining a ViewModel for every Model. So I guess the question is: what's so bad about letting the Model have UI oriented code, as long as you separate it in the source code and don't use the UI aspects of the Model inappropriately?
The point is separation of concerns. Your ViewModel is built specifically for the needs of the UI; that means the data it contains is formatted specifically for the UI, whereas your Model is formatted directly for your persistence or domain logic.
In your situation, changing your model necesarily requires then that a change is also done to the view model; when separated, each can vary independently which reduces unintended side effects.
what's so bad about letting the Model have UI oriented code, as long as you separate it in the source code and don't use the UI aspects of the Model inappropriately?
Nothing if you have a complete set of unit tests and are willing to update all locations that are using your model if it changes, or if you can guarantee that your database will never change.
You can't really "enhance" your Model instead of using a viewModel. In theory you could, but it would be very bad code.
Just a simple example:
Imagine that you have a class User with only 2 fields: userName and password. This User class is your model.
But on your page you want to add one more field to edit/add the data: the password verification field.
So are you going to add password2 field into your User class?
That's bad!
Instead you better create a ViewModel binded to your View and based on the data of your ViewModel then you create the instance of your Model and process it in the other layers
I am using automapper to map my models to viewmodel classes to pass to my view.
My question really is where should the validation go? I was planning on using the MetaData decorations - a feature of mvc 2.
But either in the model or viewmodel? Or in both places?
Validation should be done minimum at the View Model because this is what you receive as action argument and contains the user input. You could also have validation at the model.
My answer would be ViewModel because Model can change (for example from using Linq2SQL to EF). This way when you plug another Model you still have your validation intact.
I personally have my validation 2 places using DataAnnotations. My model is not passed up to my view in full. I have separate models for my views and translate the data from the view model into the model. This way, I can put whatever I want in my view model and leave out the pieces I don't want to deal with.
My reasoning, however, is that I have a windows application and an web application using the same model. This way, the same set of validation rules govern the Model for all apps, and my view model can have slightly different rules if need be. Of course, this creates a "duplication of logic" - well, validation logic.
This way I don't have to rebuild the data that wasn't used on the page every trip back to the server or put it in hidden fields and inflate the size of my pages.
You should put validation that is specific to the UI in the ViewModel, and anything that is related to business process or database validation in the Model. These might overlap.
The model should implement the validation it needs to ensure that its state cannot become invalid; that validation most definitely belongs on the model.
for example, a book class must guarantee that its title must be between 1 and 50 characters, its id must be >= 0 etc.
business rules belong elsewhere (in your controllers if you only have the model view and controller layers). this might be something like a user cannot add more than 3 books if their email isnt verified.
validation in the view should be restricted to parsing user input for invalid data: anti xss, sql injection, out of range. etc