I creating my first WPF application, and the goal of this is to basically be a data entry application for the database for CRUD operations (for example, creating a new customer in a new window, editing a customer, displaying a list of customers, etc). A database has been created, and I have thus created a Models folder to contain the .edmx file, dbcontext stuff, and partial classes generated from ADO Entity Data Model tool.
EDIT:
My question is, now, how do I go on with MVVM with my ViewModel and Models working together. All the tutorials I have seen show starting from scratch, and not using existing classes. For example, all tutorials would show creating a brand new Customer class, vs just going off the partial Customer class that was created for me.
I don't want to start over, so how do I follow these tutorials alongside the classes that were created for me through Entity Framework from my database?
In my opinion there is nothing wrong in Database-first approach, even it's quite good, because you would have general view at project (data side).
I would recommend you to start MVVM approach using Caliburn.Micro framework, it's easy, powerful and really nice.
Caliburn.Micro - getting started - part 1 - you can find there all 5 parts.
Caliburn.Micro - framework
MVVM does not specify where you start from, or how you deal with databases.
MVVM specifies you must get rid of the horrible code-behind hacks abundant in some useless dinosaur UI frameworks such as winforms and use DataBinding instead.
Therefore, just go ahead with your existing infrastructure, and make sure you don't manipulate or create UI elements in procedural code.
Related
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 have a WPF GUI application based on MVVM design and data binding. Now, I want to reuse the core code (i.e. the data model) in a Windows service, or a console UI app, or a WinForms app.
Is such a design reasonable? If yes, what are the pitfalls?
Or should I make a standalone data model instead, and interface WPF via wrappers?
UPDATE:
Sorry, I should have been more precise. Let me clarify: I don't doubt the very modularity thing =) My concern boils down to having my current DataModel implement INotifyPropertyChanged, use DispatcherTimers, etc. -- all that non-GUI but still WPF stuff. The model's business logic is based on it.
Is this (non-GUI WPF) design acceptable for reuse in the aforementioned cases, or should I abstract further, until no references to WPF would be required at all?
Yes, this is perfectly acceptable and most of the time it is desired!
When you build an MVVM app, it should be in at least 3 formal layers:
Presentation WPF, UI, xaml, behaviors. All that stuff. Not reusable
Application The view models and structure that supports your application rules. All that stuff. Not intended for reuse
Foundation Database access, business objects. Domain specific algorithms. Ideally this bit should be reusable anywhere
The foundation layer is the clever bit. This is where the meat in your application sandwich is. It makes perfect sense for this to be totally agnostic of UI technology. WPF, winforms, ASP. It shouldn't even need a UI.
Edit for question update:
Removing all references to WPF is hard because sometimes you need a CollectionViewSource on your view models for grouping/filtering of results. That is a WPF class.
It is very tempting to view your seperation-of-concerns as 'just dont reference wpf' and that helps but it can make life difficult. Instead, try to be disciplined with the type of behaviors you are putting in. If you find yourself writing 'clever' (domain) code on a view model, shift it to the foundation layer as a business object method or extension. Similarly, if you find yourself implementing IValueConverter often, perhaps you should make better use of view models.
One thing is for sure, your foundation layer should never, ever, ever reference WPF.
Such a design is very reasonable! You can create a portable C# library for all .NET technologies including WPF, WinRT, ASP MVC, etc which can contain your models. Obviously you'll need to wrap these portable models into a viewmodel anyway, but IPropertyChanged is implemented in all XAML flavors.
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).
I develop in WPF with EF (EDM designer entities).
I now want to move to Silverlight+RIA, and I am looking for a turorial, video or whatever that will guide me how-to to use Silverlight RIA with MVVM using EF as the model.
I have extensive knowledge of: .NET 4, WPF, XAML, DPs, DataTempaltes, EF 4.
I am familiar with Silverlight, WCF RIA and MVVM.
There are two things about LOB+MVVM I am encountering difficulties:
I am looking for a way to template my work, so I don't have to copy-paste the content of my ViewModels, what I mean by that is having a generic ViewModelBase that will handle a certain type of Model(s):
ViewModelBase where TContext : DomainContext, TModel : Entity`
Another difficulty is the overall composition of the UI; say I have a branch of master detail that gets complicated more and more all in one screen. I want all the parts to be divided into tiny Views each for its point. The problem is, I don't know how to expose the data for the inner views, say the main view's DataContext is set with MainViewModel, and there is a property Contact in the MainViewModel; how would you set the Contact view inside the MainView, setting the inner view (the ContactView)'s DataContext to ContactViewModel AND setting the ContactViewModel's Contact to the current Contact from the MainViewModel, what is the right technique??
NOTE: I am self-employeed, no teams and not other developers, so I don't see a reason splitting everything into modules, I don't mind if the whole project will reside in one project split into folders etc.
I always find Mike Taulty's blogs useful for this sort of thing.
So try this followed by this.
And on the MVVM side of things I use the MVVM Light Toolkit, also try watching this very good video by Jason Dolinger
I am kind of new to the whole MVVM pattern, and am trying to wrap my head around it. What I am currently trying to figure out is: in a well structured solution where do the ViewModels live?
Currently my design looks something like this (sort of):
Application (The view)
DomainSpecificCode (ClassLibrary)
Gateways (ClassLibrary)
If I were to add on another type of view (for instance ASP.NET or Silverlight), where would be the best place for the ViewModels to exist?
ViewModels should go in the Application layer because they tend to be technology-specific.
For example you may want to databind a View attribute to a particular color based on the state of the ViewModel. However, Color is implemented by different types on Windows Forms, ASP.NET and WPF, so you wouldn't be able to reuse the ViewModel accross different technologies.
If you add new Applications, you must also provide new ViewModels.
Recently, I built a MVVM Desktop application that had 2 flavors:
WPF Document Base GUI
Console application
Both exe were using the same view models, one was WPF and the other one was not.
I was able to split my solution into the following projects (libraries/exe):
non-project related re-usable code (called Common)
project models + persistence
project view models
WPF application + views
Console application
It was amazingly easy to build the console application version just by using the View Models. The console application code had less than 200 lines of code, and was basically loading the ProjectViewModel and doing operations on it.
This article describes a concrete Architecture for WPF MVVM Applications.
Layers:
Presentation Layer: Views
Application Layer: ViewModels
Domain Layer: Domain specific code