I am getting started with Entity Framework using EF4 in VS 2010 RC. So far, I have done some simple console apps where I create an EDM, query it using LINQ to Entities, and output the results to the console.
Now I am building a demo WPF app to learn how to integrate EF4 with WPF. I use MVVM in my WPF apps, where each view (more or less) has a view model that includes data properties to which controls are bound. For example, my WPF demo app has a Customers property in the view model to which a dropdown in the view is bound. And as you may have guessed, my EDM contains a Customer entity.
Here is my question: How do I connect the LINQ to Entities results to my view model property? When I query against my Customer entity, it appears that I get an IQueryable<Customer> back. But my view model property is of type ObservableCollection<Customer>, which I need for the data bindings to work. So, how do I get from the IQueryable<Customer> to ObservableCollection<Customer>? Thanks for your help.
According to MSDN, the ObservableCollection constructor can take a List<T> or IEnumerable<T>. Let's suppose queryable is your IQueryable<Customer>:
ObservableCollection<Customer> ocCustomer = new ObservableCollection<Customer>(queryable.ToList());
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 VS11 beta WPF application with a Microsoft Datagrid based on a table from an Entity Framework 5.0b2 model (from an sql server database). (The grid uses whatever code was autogenerated by adding a data source from an entity framework model and dragging and dropping a table from that model to the design surface.). I then used the EF5.0 DBContext code generator add-in to generate DbContext types that I could use in the app.
The result was not good. I got a compile error that seems unfixable; at least my attempts made things worse. The datagrid does not like DbContext and doesn't co-exist with it (when both the datagrid and DbContext are based on the same database and tables). Is there a workaround, maybe by changing the code generator template?
The error message is pasted at the end. Thanks for any help or insight on this.
(note the following closely related post isn't an answer because though I can convert dbcontext to objectcontext, I can't get datagrid to work properly with it when I do; and if I convert objectcontext to dbcontext, I don't have the autogenerated dbcontext types:
Convert DBContext to ObjectContext for use with GridView). I'm looking for a fairly simple workaround--I'm sure there's a workaround if I start hand coding all types and conversions, but I want to keep the ease of using the autogenerated code--I don't want to be occupied with work the code generator can, and so should, do. If there isn't a solution, I suppose I'll base the controls on ado.net and leave entity framework for non-ui code.
Error
Cannot implicitly convert type
'System.Data.Entity.DbSet' to
'System.Data.Objects.ObjectQuery'
Documents\Visual Studio 11\Projects\WpfApplication3\WpfApplication3\MainWindow.xaml.cs
The line that caused the error (created by Microsoft drag and drop of the datagrid with an EF table as the source):
System.Data.Objects.ObjectQuery myTblsQuery = myDbsEntities.MyTbls;
The code gnerated by drag and drop in the WPF designer was never very good and the WPF team haven't updated it to work with DbContext. Your best bet is either to drop down to ObjectContext like the other answers suggest or to use the much better WPF data binding supported by DbContext but do so without using drag-and-drop.
WPF data binding with DbContext is pretty easy because the Local property of each DbSet is actually an ObservableCollection which WPF naturally binds to very well. So for example you end up binding your view sources something like this:
categoryViewSource.Source = _context.Categories.Local;
This blog post contains more details: http://blogs.msdn.com/b/adonet/archive/2011/03/14/10138486.aspx
I'm working on a Windows Phone 7 app with a designer. I've done C# development with XNA so I know C# but was not familiar with the Model/View/ViewModel architecture.
Our first crack at it had multiple ViewModels active for any given view. Each ViewModel was an in-between layer for each object in our model.
For example: We had a "Friends" page that has a ListBox that displays the list of Friends. So we made a FriendsListViewModel that would handle getting an ObservableCollection<Friend> from the Model that the XAML would bind to. There were other functions available in the page (navigating to other pages, activating semi-related features, etc.) so that was contained in the FriendsPageViewModel.
This was starting to look crazy to me, so I made the relationship between View and ViewModel 1:1.
With all that described, I've got a question with two components:
With MVVM, what is the common relationship between Views and ViewModels? (focusing on Windows Phone 7 development here in case it's any different from ASP.NET, WPF, or Silverlight)
And as a possible addon to that question: Say the 1:1 relationship is the generally correct or accepted one: If you're dealing with something like a Pivot control or Panorama control, would you typically give each PivotItem or PanoramaItem its own ViewModel?
In MVVM, you typically have one ViewModel for each View (exceptions exist). The View typically 'binds' to the ViewModel which is the glue between the view and the data model. Your view can contain multiple controls and each control will bind to a particular property (i.e. data source) on your ViewModel. The ViewModel will then notify the View once one of these properties is updated (via the INotifyPropertyChanged interface in C#).
When thinking about ViewModels, don't think of it as a single ViewModel per control. Think of the control binding to a single property of the shared ViewModel.
The ViewModel provides data from the model to the View. The View should only be used to display the data it gets from the ViewModel. Keep code in the View to a mimimum and only pertaining to rendering control elements. The ViewModel is responsible for querying data from whatever the data source may be and then providing public properties the View can hook into.
This MSDN link has a pretty detailed article on it, but you can get a good synopsis on wikipedia.
I work wpf application by using mvvm pattern. I have model with classes which implement INotifyPropertyChanged. How to insert some data in database using LinqToSql? I also added LinqToSql class in my model.I watched for Repository pattern and Unit of Work, but I need help
your question isn't very specific, but there are a few steps you need to take:
create an object model that resembles your data model (i.e. you need to create a class for each of your tables, declare their keys etc) - this can be automated (see here)
create a DataContext class that represents your database - you will need this to get and submit your changes to the database
after you've made changes to your object model, submit the changes to the database using the data context.
there are plenty of examples on the web, such as this one
I am using a WCF service reference in a WPF project, and my entity framework data model resides in WCF project.
And I am using MVVM Light framework. I am doing the following things:
I use LINQ in the service to get data and then fetch it from WPF, obersvablecollections usually.
Everything works in view part like populating datagrid, views as required.
But I have following doubts:
Is this correct way of transferring data between wcf and wpf.
I haven't used the Model for anything yet, I have doubt about when to use it?
I also wanted to save data from datagrid. I was able to pass on the observablecollection of updated data of datagrid to the service's function. But how do i update the entity from this collection? by looping? doesnt sound right. Once I update the entity from this collection I will be able to use saveChanges to update into database.
When I need to show hierarchal data in a treeview, where to make that data hierarichal, from stored procedure xml? use a view to create a grouping criteria column? create this column in service? create this column/property in presentation?
1 - There is no correct way, it depends on your requirements and goals.
2 - With MVVM, the model should sit between WPF and the database. That means all calls to the database should go through the model, and all writes to the database should also go through the model. The WPF GUI should only bind to the model. This usually means that your WPF portion consists mostly of XAML code. All code that accesses the database should be in the model.
There are good reasons for separating this.
You can write unit tests that on the model.
The view model is independent from the look of the GUI. This means that you can easily change the GUI by dropping in different components and just binding to the model.
A quick google search can probably yield more reasons.
3 - I would try to send over only the entities that have changed. This can be done by passing the collection to your view model, and have your view model figure out what has changed.
4 - I don't quite understand what you want to do. Usually, to make a TreeView, you should create HierarchicalDataTemplate for each of your view models. The TreeView control will take care of the rest. You should really do some tutorials on this one, because it's kinda hard to wrap your head around.