Suppose I have VM with some entities as property. Say People, Addres, Phone, ....
Then I want to implelemt IEditableObject on VM so that user have undo functionnality.
What's the best way to implement request?
Demo code please.
Have a look at following two links which have good examples
http://www.a2zdotnet.com/View.aspx?Id=135
Using IEditableObject In Silverlight
IEditableObject doesn't make sense on a view model since all commands from the view such as Edit, Cancel, etc. are implemented in the view model itself. At best you can use IEditableObject internally in your view model on the data classes to make them easier to manage.
Related
I am trying to understand the MVC Pattern, and I finally understand a lot of it. There is one concept that I don't quite understand yet. I have looked through all the posts on here that try to explain MVC, but this one question isn't answered clearly yet.
Do you create variables in the model or the controller or both?
I can see someone passing variables from the controller to the model to change the data held within the variables, but would it be better to create them in the model then just call their values from the controller? Or would it be better to create variables in the model, and copy their values to the same variables in the controller?
If you know, please explain why one is better than the other, please. I am asking to understand, not just to know the right answer. Thank you.
If I give a straight forward answer for
Do you create variables in the model or the controller or both?
It doesn't really matter.
The main idea behind Model and Controller is
Controller resides only Presentation Logic.
Model resides only Business Logic.
So that, if you want to present your model with a different presentation logic, you can get your existing Model out and plug it with a new Controller without any problem because your business logic & presentation logic is decoupled(not mixed with each other).
This is the best diagram I found for MVC architecture. Hope you can upgrade your understanding with this.
So in terms of variables, in Model you should make variables only for business logic purpose. In Controller, it's only for presentation purpose. :))
Persistent data needed throughout the lifetime of the application should be held within the Model. Model method calls to set, get and manipulate the data within the Model should be done by the Controller.
Temporary data needed by the application or the view (for any reason) can be held in the controller... but no persistent data should ever be held within the controller, as it's considered to be a bad MVC design pattern implementation to do so.
Should the view know the model:
or not:
?
Programmers often shortcut this and make the view specific to the model. For instance, if you're in a CRM app the model might have a firstName field; the view then assumes the model object it's given has a firstName field and shows that in the appropriate place.
This of course isn't reusable. If you are making a View to display a table of data, it shouldn't care which model field is shown in which column. It should just handle displaying and formatting tabular data in a generic way. But if your view is of a web page that's custom-built to the specific data it's showing, it can be okay.
So you have to decide on a case-by-case basis whether you want a view to know about the specific data it's showing or if you want it to be a reusable component.
In either way, any changes to the model's data should always happen through the controller. The controller is responsible for enforcing your business logic, and that's impossible when something else is circumventing it.
No, the model and view communicate through the controller.
I mean, you can have them know each other, but that would induce tight coupling and would be hard to extend the functionality of the application.
By rights, Model, the underlying business entity, shouldn't be exposed directly to View. We normally use ViewModel, a presentation-specific model, which is derived from one or more Models.
I'm learning ASP.NET MVC from the book Pro ASP.NET MVC 4 (which I love so far, by the way).
I'm still in the beginning chapters and it's showing me the System.ComponentModel.DataAnnotations namespace attributes, how to sprinkle my model class with these annotations, and then how to use them to check if the model is valid (ModelState.IsValid in the Controller).
For example:
public class GuestResponse
{
[Required(ErrorMessage = "Please enter your name"]
public string Name { get; set; }
}
...
public ViewResult RsvpForm(GuestResponse guestResponse)
{
if(ModelState.IsValid)
{
return View("Thanks", guestResponse);
}
}
There are a couple things about this that make me uneasy.
Why do I want a bunch of attributes littered throughout my domain model? I like my domain model pure and free from any stuff that is implementation specific, and any real world model would be too complex to just use declarative validation like this.
Aren't the ErrorMessage parameters of the validation attributes somewhat View related? Doesn't something like that belong in the UI layer? For example...what if due to space constraints I want the mobile version to instead of saying "Please enter your name" say "Name required"? But here it is in my model!
Why do I want to use ModelState.IsValid to determine the status of the model? Shouldn't the model tell me? I understand that ModelState is making use of the DataAnnotations attributes that are in my model, but this seems like it would only work for very simple models. A more complex model might not even have a valid/invalid state, it might just have various stages and states. I'm sort of rambling here, but I don't like the idea of declaratively saying what makes my model valid or invalid.
Any advice, reassurance, or validation of these thoughts would be appreciated.
Here are my answers to your questions:
1) Why do I want a bunch of attributes littered throughout my domain model? I like my domain model pure and free from any stuff that is
implementation specific, and any real world model would be too complex
to just use declarative validation like this.
You absolutely don't want this. What you want is to have a view model which is specifically designed for the purposes of your view. It is this view model that will contain the data annotations, not your domain model. Then the controller will map between the domain model and the view model and will pass the view model to the view. Think of the view model as the projection of one or more domain models. In order to simplify the mapping between your domain and view models you may checkout AutoMapper. The basic rule of thumb is that a view should not be aware of your domain models.
2) Aren't the ErrorMessage parameters of the validation attributes somewhat View related? Doesn't something like that belong in the UI
layer? For example...what if due to space constraints I want the
mobile version to instead of saying "Please enter your name" say "Name
required"? But here it is in my model!
Completely agree with you. That's the reason why you should have a view model class which is specifically designed for the purposes of the view.
3) Why do I want to use ModelState.IsValid to determine the status of the
model? Shouldn't the model tell me? I understand that ModelState is
making use of the DataAnnotations attributes that are in my model, but
this seems like it would only work for very simple models. A more
complex model might not even have a valid/invalid state, it might just
have various stages and states. I'm sort of rambling here, but I don't
like the idea of declaratively saying what makes my model valid or
invalid.
Once again I agree with you. Declarative validation (such as what you get out of the box with Data Annotations) works great for Hello World type of applications but once you start writing real world applications with complex validation rules you quickly realize that the declarative approach simply doesn't cut the mustard. It is for this reason that I use FluentValidation.NET. It provides you with a very nice and fluent syntax to express arbitrarily complex validation rules, it integrates easily with ASP.NET MVC and allows to unit test your validation rules in complete isolation.
Data annotations is just one way of doing it. You can also use the Fluent API for defining the schema of your database and mapping ER. The annotations are tightly coupled with the front-end jQuery validation codes thus comes in handy and easier.
And yes indeed if you don't want annotations in your business logic you can use view models in your UI layer. That would entirely depend on the scope and size of the application as to the extent of view models that you would end up using.
Here's some blog you can refer to clear up your doubts on EF
http://msdn.microsoft.com/en-us/data/jj591620.aspx
Hope this gets you going.
The answer to this is very dependent on the problem you are attempting to solve. For instance does your domain contain complex business logic or is the application CRUD-based. You should attempt to pick the best for the problem you are trying to solve.
I guess there are 2 extremes when thinking about these "domain models" they can simply be data transfer objects between the database and UI, or, they can be complex DDD type object that model the business problem. If they are the former then why not keep them as simple as possible. On the otherhand complex business domains would be hard to implement well using a 'single' model which is shared between view and db. In reality you are probably somewhere in the middle.
2 & 3. Yes they are, but does that matter for your "note" application, how about for your shipping app?
I'm fairly new to MVC4, EF5 and ASP.Net, and I don't seem to be able to find a good answer anywhere.
Basically, Should everything be done through the viewmodel or is it Ok to also incorporate viewbag?
Say I have a method which populates a drop down list, and I am using a viewmodel to represent the output for the view.
Am I ok to use Viewbag.DropDown = PopulateDropdown(); or would it be better to incorporate
this into the ViewModel, by creating a property to hold the List<SelectListItem> created by PopulateDropdown(); ?
I know how handy ViewBag is, but I'm yet to see any solid reason as to not use it? If anyone could also offer me some more insight, that would be fantastic.
Basically, Should everything be done through the viewmodel or is it Ok
to also incorporate viewbag?
Everything should be done inside a view model. That's what a view model is. A class that you specifically define to meet the requirements of your view. Don't mix ViewBags with ViewModels. It is no longer clear for the view where is the information coming from. Either use only a view model (approach that I recommend) or only use ViewBags. But don't mix the 2.
So in your particular example you would have a property on your view model which is of type IENumerable<SelectListItem> and inside your view you will use the strongly typed version of the Html.DropDownListFor helper to bind to the model:
#Html.DropDownListFor(x => x.ProductId, Model.Products)
Obviously those are only my 2 cents. Other people will say that mixing ViewModels and ViewBags is fine and I respect their opinion.
Prefer ViewModels over the ViewBag wherever you can. Create Strongly typed views. It makes your code cleaner, less fragile, less error-prone, and easy to maintain.
ViewBags are just dictionaries of dynamically typed objects so you lose:
Compile time checking
The ability to refactor with confidence (you lose the support of the tools)
IDE support - such as the ability to navigate to all usages
Intellisense
For bonus points making extensive use of the ViewBag also misses the point of using the MVC pattern
I get the impression ViewBags were created to solve an edge-case problem in asp.net and people use them instead of creating view models as was originally intended in the design of the platform, to the detriment of their work.
with thanks to Why not to use ViewBag heavily?
For example: Let's say I'm grabbing a list of names and saving it to an NSMutableArray. Do I implement the method of actually calling the server to fetch the data in the controller (UIViewController) or the model(Friends object)?
It's a design decision that depends on what you're trying to accomplish. If your model only makes sense in the context of a single service, or if you want your model to provide access to all the data on the server, then build the connection to the server into your data model. This might make sense if you are, for example, building a client for a service like Twitter or Flickr.
On the other hand, if you're just grabbing a file from a server and that's the end of it, it may make sense to do the communication in the controller. Controllers tend to be less reusable and more customized for the particular behavior of the application. Keeping the specifics about where the data comes from out of the model makes the model more reusable. It also makes it easy to test -- you can write test code that just reads a local file and stores the data in the model.
That's a good question. I think the best way is through a controller because it decouples your model from requiring the other model to be present for it to work properly. Although I don't think you violate "proper mvc" by doing it in the model either.
I think you want to put it in the model. What you'll do is interrogate the model for the data and then the model will handle how to populate itself whether it's from an internal data store or an external one (like a server).
One approach is to use the repository pattern. To do this, you create Repository objects in your Model folder and you place all of you database-related methods in them. Your controllers call the repository classes to get the data. This allows you to separate the real model objects from the database accessing methods.
I use the MVCS pattern (Model-View-Controller-Store), which I discovered in Aaron Hillegass's book "IOS Programming: The Big Nerd Ranch Guide" (http://www.bignerdranch.com/book/ios_programming_the_big_nerd_ranch_guide_rd_edition_)
The store is specifically designed to fetch the data, whether it comes from a server, a local file, a persisted collection, a database, etc.
It allows to build very evolutive applications. For example, you can build your application based on a web service, and the day you want to persist your data, you juste have to modify the store, without having to modify a single line of code in your controller.
It's a lot like the Repository Pattern (http://msdn.microsoft.com/en-us/library/ff649690.aspx) (cf BobTurbo's answer)
I'd personally make a DAO, or data helper class. It's very hard to follow the strict MVC in objective C when things get more complicated. However, putting it in the model or the VC is not wrong as well.