I have the following problem:
In my Application I have to connect to an Access Database - yeah, I know that Access isn't a great database - but I have to use it.
The Application will be written in WPF, with the MVVM Light Toolkit and "NHibernate".
How do I connect "NHibernate" with the MVVM Light Toolkit?
Do I use the Hibernate Entities as "MVVM" Models?
And what's the best place to store user settings which are only need on runtime?
how do i connect "NHibernate" with the MVVM Light Toolkit?
Given the Three Layer Architecture, you should differ your GUI from you Database layer.
This means that you shouldn't tie your MVVM framework and your ORM framework together.
Among many other disadvantages that this binding will have, it will create high coupling between your GUI and DB, and make it extremely hard to replace, if oneday you'll want to change some of those frameworks.
Do i use the Hibernate Entities as "MVVM" Models
The ultimate loose coupling will be to create a different assembly to store your entities, which you can reference both from you GUI, where they will act as "MVVM" Models, and from your DAL, where they will act as NHibernate Entities.
what's the best place to store user settings which are only need on runtime?
The best place to store user settings are in the App.config file under the <userSettings> tag, which you can also do from the .Settings file under the User scope.
You can easily access them :
var mySetting = Settings.Default.mySetting;
If you want settings that will be available only as the application's lifetime, you can create properties in a static class to hold your settings:
public static class UserSettings
{
public static string MySetting { get; set; }
}
Hope this helps
Maybe read this article to get started with the MVVM pattern.
No you would not use the nHibernate entities as ViewModels in you application otherwise you would have a MVM pattern or something like this ;)
It's usually not a good idea to use entities as models exposed to the front end directly because you would mix up data and UI layer...
Related
Trying to build a single user Desktop application using
WPF as the UI
Prism for MVVM and other frills
Unity being the preferred DI
Entity Framework as the preferred ORM
I've read about using EF in desktop scenario as above and guess the following are the two possible ways of going about it...
Use the DbContext in the ViewModel directly (ties you to EF permanently)
Use the DbContext in the ViewModel via DI (abstraction)
I prefer the second approach, and tried the following path.
Use Interface and Implementation classes that abstract DbContext
Create a Service Layer that uses the above
But now, I'm afraid I've lost all the cool change tracking that EF offers and my models are on their own to track their state and inform the DbContext of their state when reattached to it...
While its ok in a web app with WCF services and all... it seems overkill to enable my model with change tracking, for a simple single user desktop application...
Do I make any sense here? Am I getting anything wrong or missing something.
Need help, thanks in advance.
Cheers.
I created database in management studio, a model in my project with the ADO.NET Entity Data model for the tables.
I want to use the MVVM pattern to build forms and update, delete, insert data in my forms.
Can you please give me some guidance how to map the models with my viewmodels. Any tutorials would be nice, I`ve already spend whole day looking for something but got confused at the end.
Is there a simple project with Entity Framework and MVVM.
This is a bit of a contentious subject but I personally don't view change notification as belonging in the exclusive domain of the view/view-model relationship, so I add INPC to my models as as well and expose them in their corresponding view model. This can be done by either injecting proxies into your repositories at runtime (e.g. Castle Dynamic Proxy) or by modifying the IL automatically at compile time (e.g. Fody).
From one noob to another - try searching for 'wpf mvvm entity framework example'. Here's what I found useful...
http://www.software-architects.com/devblog/2010/09/10/MVVM-Tutorial-from-Start-to-Finishhttp://social.technet.microsoft.com/wiki/contents/articles/28209.wpf-entity-framework-mvvm-walk-through-1.aspx
First you can use the repository pattern, to abstract your data access layer, so you viewmodels don't have a tight coupling to Entity Framework and remain easy to test.
Second, you can use an auto mapper like AutoMapper to map from your models to your ViewModels. However, you shouldn't use automappers to map from ViewModels to the View, so you'll have to manually create your model and pass it to your repository for insertion or updating.
I am trying to create a WPF project with MVVM and ADO.Net Entity Framework.
I do have a few questions though.
Do i create the Entity Framework Model in the Model Folder of the MVVM Design?
Or do i have to create a new project for each item of the MVVM Model(i.e Views Project as
a WPF Project,Model Project as a class libraray, ViewModel project as a class library)?
It doesn't really matter where you put stuff, but yes I usually put all my EF or Linq-Sql stuff in a Model folder as they will usually house all of my model classes anyway and it keeps it all together. It is a bit of a grey area though, because it's also doing DataLayer stuff, so just bear that in mind too.
Regarding your 2nd point, no. The Model, View Models and Views should all be in the same project.
Take a look at this for some guidance on MVVM.
Do i create the Entity Framework Model in the Model Folder of the MVVM Design?
I usually create a separate project for the model which is storage ignorant (using POCOs) and also usage ignorant.
Or do i have to create a new project for each item of the MVVM Model(i.e Views Project as a WPF Project,Model Project as a class libraray, ViewModel project as a class library)?
If you are planning on having more than one type of view-model per model (e.g. one for WPF, one for a service, one for another service), then separate your view-models into their own assembly.
If your views only represent one model layer, then you can start out your views and view-models in the same assembly, then separate them if you get to a situation that you have multiple models under the same view (each with its own view-model).
You should also consider if you want the ADO.NET's model to be your main model (upon which you base your view-models), or if you want to treat it as a sort of view-model for storing (where the storage service is a sort of view).
We are about to start up a new project similar to a previous one. I could just copy the old design but I am not all too satisified with the old design.
It is a "standard" business system (sales,stocktaking,warehousing etc) built ontop of .Net 3.5 (Winforms MDI) with Entity Framework in the backend.
All forms inherit from a baseform (which inherits Windows.Form). The form exposes a property called ObjectContext, which on the first call instantiates a new ObjectContext. This makes up a pretty good UnitOfWork i think, having all data-access isolated in each form.
However.
I have encapsulated all queries and common CRUD in "poor mans repositories". These Repositories are exposed as properties of the ObjectContext.
So if I wanted to bind and order to a form I would call
OrderLinesGrid = ObjectContext.OrderRepository.GetOrderLinesByID(orderID).
The OrderRepository gets a reference to the objectcontext created for the form, like this
(In my partial ObjectContext class)
Private _OrderRepository as OrderRepository
Public ReadOnly Property OrderRepository as OrderRepository
Get
if _orderrepository is nothing then
_orderrepository = New OrderRepository(me)
end if
return _orderrepository
End Get
End Property
What I do not like about this is:
The call to the repository is made
through ObjectContext. Hence, I do
not get abstraction between the
query and the dataaccesslayer I
would like.
For each new type in my Domain I
need to create a property in my
ObjectContext
My call to OrderRepository should just return domain objects and not worry about how it is persisted. Also, I cannot have each Repository have it's own ObjectContext since that would require me to Attach and Detach objects when referencing i.e Country to a Order.Country property.
I would appreciate any ideas and feedback on this design :)
I suggest you research "onion" principle , Repository pattern and Luw pattern.
There are many examples on the web.
Essentially you use POCO Model Core Project. No references to DAL project.
You declare interfaces for the Repository and luw patterns in the CORE project.
So Now a
UI layer -> instantiate context and DAL Object eg repository -> inject into CORE services.
Also connected to this approach is Inversion of Control or dependency injection pattern.
If you use test driven development against Dummy Repositories you can make sure the design principles are adhered to.
Following on from this initial investigations on Silverlight architectures, I have some new requirements to consider.
We expect our Silverlight client UI to be graphically heavy, with a GIS interface, multiple charts, gauges and datagrids arranged in a Widget style fashion. New widgets will be dynamically generated by the user.
Suppose a user wanted to dynamically create a chart widget from an existing datagrid widget pre-populated with data. It appears to me that if we were using a MVVM pattern with the view model on the server, this would result in an unnecessary call back home when the required data is already located in the client.
Now obviously the server needs to know about this new chart widget on the client, but how do I create the widget in the client first (with the existing client side data) and then notify the server about the new changes?
In our intranet, the network link between the client and the server is not particularly good so performance is critical.
It seems from my initial research that the common Silverlight architecture patterns call for as much of the business logic to be pushed back to the server. I understand the reasoning for this, but fear that it will really hurt the usability of our application.
Are there particular design patterns that address this issue? Is this 'client-binding' supported within MVVM, Prism or other common Silverlight architectures?
Is there a more formal name for what I am attempting to describe?
I am quite new to both Silverlight and design patterns such as MVVM, so please correct me if any of my assumptions are wrong.
The MVVM pattern is for separation of concerns. It does not define how or where you get your data.
The model, is data. It can be data you get from any arbitrary source. In silverlight, the most common way to get data is via a webservice (SOAP/REST). But your model can be any data from anywhere.
The view model is just another class that probably implements the INotifyPropertyChanged interface (So you bindings can automatically be updated). This class is an abstraction for your view's data. Let's pretend it has a string property called "FirstName".
The view is your UI (A user control in SL). You setup your bindings here to your ViewModel. IE, .
The view and view model are put together when you set your views DataContext. myView.DataContext = new MyViewModel(); There are many ways to set the DataContext depending how you want to set things up.
Prism is just a framework to help write decoupled applications in WPF/SL. It does not enforce the usage of any UI pattern (ie, MVP/MVC/MVVM). What it does come with is a bunch of classes can be used to assist with MVVM development, such as a mediator (EventAgggregator) and a dependency injection container (Unity).
So enough digressing...What I would suggest, is you have a web service where you can get all your data. You SL app would get that data (most likey the web services will be called in the view model). That data now exists on the client side and you can setup your VM to bind to this data in your view.