I'm creating a JavaFX application which implements the concept of a view, a view controller and a data model. The view controller creates an instance of the data model and defines some bindings on properties. So far, this works fine.
Now, there is another class which implements some business logic. This class also needs access to the data model as it uses a subset of these data.
What would be an appropritate way to "share" this data model between the view controller and the business logic?
Using a singleton for the data model?
Passing the data model instance to the business logic?
...
Related
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.
I've an ASP.NET MVC project with a domain and a data layer (contains just EF and migrations).
Now, I have to validate a Client's VATNumber field with a specific formula I'm having doubts where to place it.
I would like to use the Controller's ModelState to check if the field is valid, using a EF DataAnnotation ValidationAttribute, so I don't have to validate it in the Controller's Saving Method. But I'm conflicted having to put business logic in the data layer.
Is there some kind of alternative to ValidationAttribute, so it can be "injected"? Or I'm just looking at this wrongly?
Validation attributes is not part of Entity Framework.
If you want splite data layer from presentation layer, you can use Viewmodels and bind them on datamodels with Automapper. In this case you place domain validation on viewmodel and validation of datalayer on datamodel.
In very complicated cases you may have three models: viewmodel, domainmodel and datamodel, but in common cases viewmodel and datamodel is enough.
In an mvc project, could someone explain to me the difference between a model and a view model?
My understanding is that a view model reperesents the data for view eg. cshml, but a model represents the data for a partial view. Would this be correct. I have seen the names used in different situations which confuses me so looking for direction on this.
Models are your domain. For example we might have a customer model. We can use this customer in our domain. We can place orders for this customer. We can update the customers contact details, and so forth.
// Domain object, encapsulates state.
class Customer
{
public void PlaceOrder() {...}
public void UpdateContactDetails() { ... }
}
View Models are a way of presenting the data in an easy way. For example, we might have a customer view model. This would be a simple DTO (Data Transfer Object) which allows us to expose the customer to a view. Often view models are created from models - some form of conversion often takes place.
// DTO - exposes state - no domain logic
class CustomerViewModel
{
public string Name { get; set; }
public int Id { get; set; }
}
The benefit of using a view model rather than using your domain objects in your views is that you don't have to expose the innards of your domain to ease presentation logic. I should add that view models are a way of controlling model binding, e.g. if you expose a database record you probably don't want the whole record to be bindable. Using a view model means only those parameters on the model will be bound. Therefore using view models is important from a security point of view. The alternative here is to use whitelists to control what is used during the model binding process - naturally this is tedious and prone to error.
In terms of ASP.NET MVC - the word model is used somewhat interchangeably. In a "real world" project, your domain is likely complex and will not reside inside a Web App, chances are you'll include some other dependency. Therefore the "models" you'll use will be View Models.
In general, in the ASP.NET world, when people refer to models to refer to 'domain models' which are often a 1-1 mapping between say a database table and a C# class.
When referring to view models, these are convenience classes which aid the passing of data between the view (.cshtml) and controller.
The view models should contain data relevant to the view, which may contain aggregation data of the domain model (e.g. a property called 'FullName' which is the combination of 'FirstName' and 'LastName') or things like paging info etc.
Personally I prefer to use view models to present data in simple forms to the view, and I make the controller actions take instances of a view model, construct domain models and act on them, either directly or through a service layer.
I'd say that is general a view model holds the data for a specific view/screen/partial view and a model is rather the object representing the business object or entity.
Please look into the following posting, your question was successfully answered:
ASP.NET MVC Model vs ViewModel
Hope this helps
I have an MVC2 application with the following classes:
-OrderModel
-LineOrderModel
-OrderController
-LineOrderController
In the OrderController class I'm recollecting some values of a web form . Until now, I created instances of each order line (LineOrderModel class) and OrderClass inside of the Controller.
I was trying to create a OrderFacade class in order to encapsulate the different things to do when creating an order.
So in that class I created a method like this:
public void saveOrder(int idProvider,decimal? price)
{
// Here I create instances of OrderModel and LineOrderModel
// and assign their properties
}
but my problem is I don't know how to pass all the order lines captured from the web form.
I think it doesn't make sense to create and pass to that method a List with orderLines class (because the point of this is to operate with the Facade, not with the class directly)
How could I encapsulate the different lines (all with properties like numberUnits,idProduct ...) into a List of generic objects, each one with these properties?
Maybe something like a List<List<object>> ?
Thanks in advance!
Sounds like you don't need facade. Facade would be good choice if you use data transfer objects (DTOs) between your business logic and application logic (controllers) - in such scenario DTOs can also be view models (I guess orthodox MVC developers will don't like this idea). Facade would take DTOs and convert them into some business or domain objects.
But in your scenario you simply need to fill data directly to your model classes - that is purpose of view model classes to use them in views and controllers. Using any kind of property bags to transfer data from controller to business logic is not a nice solution.
I'm learning ASP.MVC now. I got some problems of creating strong-typed view.
I added Entity Data Model to Models, and then I tried to add a strong-typed view based on the Entity Data Model I created. But I cannot see any class in "View data class" in "Add View" dialog.
Did I miss sonmething?
Build your project before you add view.
Steps I did to do this were;
Create an entities data model in a new project under the solution.
Add some objects to the EDM using the model browser.
Make a model class in the Models folder of my MVC project, then add some method that gets objects from the Entity Data Model. Don't forget to reference you EDM project from your MVC project.
In my controller cerate a new ActionResult (or View Result), get it to call for it's objects from the models folder model. Then right click and create view...
You should see your entities data model and your models folder objects in the view data class dropdown. The reason for using the models folder, for me, is so that I can make it very clear when I am lazy loading objects, for instance, order items from a parent order.