Here it is said that we have 2 options to implement MVVM with JavaFX - it depends whether we want to use JavaFX-Properties in our model or not.
As I understand if my model doesn't have javafx properties then I add fx properties to ViewModel. However, I can't understand what I should do if my model has fx properties. What should I do this case? Something like this:
class ViewModel {
private ObjectProperty<Person> personProperty = new SimpleObjectProperty<>();
...
personProperty.set(person);
}
or I should duplicate all the properties of the Person in ViewModel and bind every ViewModel property to Person properties, to get View -><- ViewModel -><- Model? Could anyone explain what to do this case?
There are 2 solutions with their own advantages and drawbacks.
If you want to stay 100% true to the MVVM pattern your View may not know any model classes. Therefore it's not allowed to give a personProperty from the ViewModel to the View. Instead you have to duplicate the fields of the model class as properties in the ViewModel, for example "firstnameProperty". These properties can now be used (typically by data-binding) in the View. The View doesn't know anything about a model class 'Person'. Instead it only knows the properties that the ViewModel provides.
However, now you have to keep these properties in sync with the actual model instance in the ViewModel. To make this easier some time ago I've created the ModelWrapper util as part of the mvvmFX framework. In addition to classic Java POJOs it also supports classes with JavaFX Properties. You can see the a usage example in the tests of the class here. It uses a Model class with JavaFX properties (here).
This is the recommended approach. However, depending on the complexity of your model classes this can get tricky. For complex models with a deep structure you might need to write your own logic to keep the properties in sync with your model classes. This is one of the trickiest parts of MVVM pattern.
The other approach is to relax the limitations of the MVVM pattern and to pass the Model instance to the View. This can be a solution if your Model class has lots of fields and it would be to much code to duplicate each field in the ViewModel. However, this way you are introducing a dependency from your View to your Model which is agains the idea of MVVM.
Related
I have a model class named Server, it contains many navigation properties and properties, which I want to prevent users from binding it. So I find two approaches of doing so to avoid over-posting attacks.
The first approach is to go to each model class and define an Exclude Bind list , with all the properties and navigating properties that should not be bind by users , as follow:-
[MetadataType(typeof(TMSServer_Validation))]
[Bind(Exclude = "Technology,IT360SiteID, VirtualMachines, TMSServer1,DataCenter,OperatingSystem,Rack,ServerModel,TechnologyBackUpStatu,TechnologyRole,TechnologyStatu ")]
public partial class Server {
}
}
The second approach is to create a view model class , with only the properties that can be modified by users as follow:-
public class ServerViewModel
{
public int ServerSize { get; set; }
[Required]
public String OperatingSystem { get; set; }
public String Commnet { get; set; }
}
I find that the first approach is faster to implement , as I only need to define the Exclude list, while the second approach will require me to create view-model class for each of the domain classes. So which approach is recommended to use and why ?
Thanks
Over-posting occurs due to the default model binder not knowing which fields you actually included in the form.
It will try to map all values in the request to object. Attackers can use your form to add additional fields to
query strings/form post data and add properties as part of the request. The default model binder won't
know the difference. Your Server class will deactivate once the mapping is complete and the update is processed.
To prevent over-posting, set the annotation to include fields in the binding, or create a ViewModel like you mentioned in your code.
So which approach is recommended to use and why ?
Both annotation and ViewModel allow binding only on specified fields, but when you use ViewModel you will not bind against business objects or entities, and you will only have properties available for the input you expected.
Once the model is validated, you can then move values from the input model to the object you used in the next layer.
k. Soctt Allen has a good article about which approach is better, you can take a look at by the following link:
http://odetocode.com/blogs/scott/archive/2012/03/11/complete-guide-to-mass-assignment-in-asp-net-mvc.aspx
It's difficult to tell without seeing the rest of your code, but in general I'd say using the ViewModel is probably a better approach for the following reasons:
You separate your view from your business logic
It is safer. If in the future someone adds a property on Server and forgets the Bind-exclude, you're exposed to over-binding without knowing it. If you use the ViewModel-approach you have to explicity add new properties
Maybe this question is a little bit ambiguous because the answers are going to be based on opinions or something. But I'll try to answer it the best I can and indeed is kind of my opinion. So this is the way I see it:
First approach (Bind attribute): Is faster to implement because you only need to add on your class the name of the property you don't want to expose, but the problems comes when you want your class to exclude some properties for one feature and other properties for another feature, and you can't add fields and sometimes in MVC, the views need more fields that the ones provided by the model class and then you're gonna need to use ViewBag or something else. This approach is very handy for fast and smalls projects, but I still don't like to use ViewBag (For aesthetics reasons)
Second approach (ViewModels): Is more work, and more time but at the end (again in my opinion) you get a cleaner and ordered code and you don't need to use the ViewBag, because you can have the perfect object to send to the view depending on what this View needs, so if you a have an object with different views, again depending on the needs, they could share the same ViewModel or they could have a ViewModel for each one. If you have a solution or a big web project, this approach is going to be very handy to keep an ordered code.
Let me know.
I've found this text in Prism documentation. I'm starting on MVVM and I'm at lost. Can (should) I bind model properties in the view or I must create a viewmodel with a proxy property for every property in the model?
The model classes typically provide
property and collection change
notification events through the
INotifyPropertyChanged and
INotifyCollectionChanged interfaces.
This allows them to be easily data
bound in the view. Model classes that
represent collections of objects
typically derive from the
ObservableCollection class.
EDIT: Here is some extra info to help. I'm building a personal project from the ground up (so I'm designing the models too), this is the first time that I use MVVM and I want to learn properly.
My model is very hieraquical, having classes with list of more class with more list inside, building a complex tree of information. I was trying the "standard" MVVM approach, build the model with POCO and no notifications, and using List. Then building the ViewModel with proper notifications and using ObservableCollections.
The problem is, the way it is going, I'm almost reconstructing my whole model as a ViewModel AND having to keep the data synched between the to (the ObservableCollection to the List). Then I read that on the Prism docs and wondered if I should have all that trouble or just create a root ViewModel for logic and bind all the rest to the model itself.
It depends really, if your model already implements INotifyPropertyChanged and/or IError info you might want to bind right to the model property. However if you want to do special validation and other stuff that the model knows nothing about you add the property wrappers in your view model.
This article gives a good example of a hybrid: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
Often my MV properties look like this and thats quite normal:
public string Symbol
{
get { return Model.Symbol; }
set { Model.Symbol = value; this.NotifyOfPropertyChange(() => this.Symbol); }
}
I often do NOT implement INotifyPropertyChanged in the model and thus often I have to write the wrappers.
EDIT: In response to your additional information: It can be a bit tricky to to keep the collections and lists in sync. In your case what I would do is to create a view model for each model class, but NOT wrap all the properties just access them like this: {Bindng Customer.Name}. But of course you have to create a wrapper for the collections which contain view models. The Prism documentation is, as they say themselves, just guidance, if your scenario needs a different approach then this is fine.
Take a look at this code. I only wrap the collections and the properties I will access through the model. This gives you the best of both worlds. Then IF you need a special property that does not belong into you model you can add it to the view model (see the CustomerViewModel), or if you need special notification for a certain properties.
class CompanyViewModel{
public CopanyViewModel(Company c){
foreach(var customer in c.Customers)
Customers.Add(new CustomerViewModel(customer);
}
public Company Company {get;set;}
public ObservableCollection<CustomerViewModel> Customers {get;set;}
}
class CustomerViewModel{
public CustomerViewModel(Customer c){
Customer = c;
}
public Customer Customer {get;set;}
public Brush CustomerBackground{
get{
if(Customer.Active)
return Brush.Greeen;
else
return Brush.Red;
}
}
}
(This code might not work, I just typed it in here.)
Now, if you need changed notification for all models and all properties you have to either implement it in you model or in wrap all properties in a view model.
I've been chugging along OK with the use of data annotations made on buddy classes so far.
When it comes to a more complex view that requires a custom view model--one that includes a few select lists, for example...would I need to then transfer my validation attributes to the view model class?
I was planning to pass the full custom view model to populate an "Edit" view, but was hoping to just receive a simple object in my "Save" action.
Where are the flaws in this plan, or is the whole thing just one big pile of fail in the first place?
Thank you.
You're still validating that data that is ultimately going back into the database. So in order to keep your application DRY, you are best off to use the Buddy Classes for the original Model.
Edit
note: this doesn't exactly have anything to do with your question
I personally prefer extend the original Model for anything "Edit" related and I prefer to use a ViewModel for "Display" only (Details pages, List pages, etc).
Example: here's my buddy class, and in it I've added a "RegionName" property that I use in the Edit Page display, but it doesn't have anything to do with the database. You can do a similar thing with custom input data that you want to validate before manipulating it into "database usable" data. I use the RegionID in the database, but I prefer to use the friendly name for the visitor instead of the ID integer
<MetadataType(GetType(UserMetaData))> _
Partial Public Class User
Public RegionName As String
End Class
Public Class UserMetaData
<DisplayName("region name")> _
<Required(ErrorMessage:="region name is required.")> _
Public Property RegionName As String
End Class
Your view model will still inherit the validation from your base model.
Don't know if this helps but I put my validation attributes against my model so that wherever i use the model i get the same validation. not ideal for some projects i realise.
actually, i put the attributes agains a partial class rather than my model because 90% of the time my model comes from a linq 2 sql file in my data repository
my controller then simply checks if the model is valid or not and the view does nothing except display data and errors really.
unsure if this is what you're asking though
i have in my flex application various mxml components that all need to show stats based on the same data. how can i go about doing that? do i need some mvc framework like cairngrom or puremvc for that or can i do it without them?
any design ideas?
You don't need any framework for that. Do you know about data-binding?
http://www.flexafterdark.com/docs/Flex-Binding
This way you can set your data as dataprovider for many components. For example to show your data in dataGrid you set in mxml it's attribute
dataProvider="{yourDataArrayCollectionIdentifier}"
and in your arrayCollection declaration you need to set metatag [Bindable]
[Bindable] var yourDataArrayCollectionIdentifier : ArrayCollection;
there are other datatypes you can use as dataprovider, just arrayCollection is the most common
There are a handful of approaches to this. For encapsulation purposes, you should isolate your shared data out into a separate class; possibly a Value Object although it does't have to be.
Then create a public variable property in each MXML Component of this classes type. When you create the instance of each mxml component, pass in your 'global' instance of the data class.
You don't need to use an MVC framework, but the Cairngorm Model Locator could also be used to address this problem. The Model Locator is a singleton. You'd store your data inside the singleton instance; and then each MXML Component would reference the singleton for the data. Creating an external dependency like this breaks encapsulation, though. I much prefer the parameter passing route for non-application specific components.
package
{
public class ApplicationViewModel
{
[Bindable] public var message:String = "";
}
}
You can now use this message across your MXML where you make the instance of that.
A singleton class is used in different scenarios where you want to hold some information of all states. A better example would be Chess Board, where your board is Singleton class and its state should never change as you have to keep track of all coins moved across the board and its position.
You are injecting this message variable in the views where you want to show the data.
I just want to make sure I understand correctly the best practices for ASP.NET MVC2 with LINQ-TO-SQL.
Please correct me if I am wrong at any of the following points:
LINQ TO SQL generates classes for
you, based on your tables
The generated classes are Models
Those are the models we are supposed to use in the Views
If we want to add validation to the models, we extend the partial class and set data
annotations. Something like this.
Generally my question is about the data validation. What I used to do is create a "shadow" Model for each of my LINQ-to-SQL generated classes and put the data validation there. Then, in the controllers I was creating an instance of the "shadow" model and also retrieve data (using Repository pattern). Mapped from the entity to the shadow model and passed it to the view. So, something like that (in the Controller):
// Car is class generated by LINQ-to-SQL, based on the Car table
// Use repository class to retrieve the data (Car)
Car car = myDatabaseRepository.GetCar(1);
// CarModel is my 'shadow' model, which has all the data validation.
// For example, it makes sure Year is before 2010 (let's say).
CarModel carModel = new CarModel();
carModel.Year = car.Year;
carModel.Make = car.Make;
carModel.Model = car.Model;
return View(carModel);
This is wrong, right (no pun intended)? It should have been only:
// Car should have been extended (as partial) and data annotation
// should have been in the extended class, rather than a whole separate
// model class.
Car car = myDatabaseRepository.GetCar(1);
return View(car);
Right?
I think it is a best practice to have a ViewModel (what you termed "shadow" model) that is used to pass only relevant data model information to a view and incorporating UI validation metadata. You can also use a library such as AutoMapper to copy over the values, rather than coding each one by hand.
A Table = Model approach can work in very simple scenarios (few tables + simple UI exactly matching database schema). In order to save yourself a lot of pain later on it is recommended to use ViewModels.