I know EF4 is still in development but as a newcomer to the subject, I need a document, tutorial etc. with EF 4 code first approach. All the info is in EF 4 Team Blog but scattered around different posts. A full coverage would be really nice.
Any one knows of a such place?
The best online resource that I've seen so far is Scott Guthrie series of blogs on the new EF “code first” development option:
Code-First Development with Entity Framework 4
Entity Framework 4 “Code-First”: Custom Database Schema Mapping
Using EF “Code First” with an Existing Database
If you are new to the subject, like you said, then they will be a perfect point to start. There is no online documentation on MSDN for the code first API by the way, as it's merely a CTP and subject to be changed.
After that you can check out the ADO.NET team blog on the Code First Development:
Entity Framework Feature CTP4 Released
EF Feature CTP4 Walkthrough: Productivity Improvements
EF Feature CTP4 Walkthrough: Code First
Entity Framework Design blog is also a great place to share ideas and give feedback to EF team. They also have the following posts on Code First so far:
Productivity Improvements for the Entity Framework
Conventions for Code-First
Data Annotations in the Entity Framework and Code First
Related
It's been a couple of years since I worked with EF and OData. Back then, OData was on WebAPI was limited to some URL filters, but even that was pulled at the last minute before MVC 4 RTM.
A lot has changed.
Now I have a model-first EF6 project with an EDMX file, since I like to visually plan my model. I am also building an OData service for this app, using WebAPI 2.2 and OData 4.0.
There's a comment on the question below:
"Unfortunately, at this time the EDM model used by EF is different from the EDM model used by Web API OData."
OData exception The complex type 'WebTools.Order' refers to the entity type 'WebTools.Customer' through the property 'Customer'
Which is understandable, the separation is best for public APIs.
However, I'm confused because the quick start tutorials on the web (see below) seem to be using the same EF (code-first) model for both OData and the database.
http://blogs.msdn.com/b/webdev/archive/2014/03/13/getting-started-with-asp-net-web-api-2-2-for-odata-v4-0.aspx
http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-v4/create-an-odata-v4-endpoint
Does that mean that the models are no longer different, the comment above is old? Or does it mean that I must go code-first if I want to just expose my database model?
And since the tutorials seemingly show exposing a single EF database model, then how does one go about separating and having two models?
I'm having difficulty finding/trusting online resources because these technologies are so fast-moving.
Luke
Here's what I've learned so far.
OData v4 does not support plugging-in existing model-first EDMX model classes.
It does support exposing an 'arbitrary' model built from POCO classes, relationships between entities are not expressed in such strong terms, but the v4 model is more like an object hierarchy and can even have a single root 'node' and all the child items and collections of items can branch off, a graph.
This is all done much more losely using just routing rules and some simple conventions for the models and controller action names.
It's therefore possible to build an OData service around an in-memory structure, or no-sql or composed of other services.
However, when it comes to an SQL source and EF, then the model must be united in order for the IQueryable logic to flow, but also for field-name mapping.
Since the OData v4 model builder only supports POCO classes, you must go code-first.
OData v4 with EF is thus limited to greenfield projects or those that feel there's enough value-add in v4 to warrant rebuilding code-first.
I am researching code-first automatic POCO generation from an existing database. This would allow the EDMX to generate the SQL database and then "roundtrip" it back into code via auto POCO generation from the DB. Having never used code-first, I'm not sure if this is something it can do.
Important As of January 2015, neither Excel or LinqPad support v4. The metadata is different, I think due to the lack of 'formal' relationships. This makes v4 not very appealing at present, especially when WCF Data Services can build a full service from an existing EDMX in a few seconds.
Updates
1/
Code-first from existing:
http://msdn.microsoft.com/en-us/library/jj200620.aspx
2/
You can exclude entities from an EF model, even if they are referenced in other entities, by applying [NotMapped] or modelBuilder.Ignore<InMemClass>(); if using the fluent API.
Luke
I've written my classes in the Models folder and I already have a database with data in SQL Express. What I want to do is just tie the two together. How do I do this? All I have seen is Code First (class creates database/tables) but that's not what I want.
As Andrew Barber pointed out in his comment, EF with Code First is the way to go, provided the classes in your modell are structurally close if not identical to the tables in your database. Even if the structure is not that compatible current versions of EF can help you a lot with the use of things like views and stored procedures.
Scott Guthrie has an excellent blog post that should get you started.
I am learning asp.net MVC, as I have been using the sqlconnection, sqlcommands etc from my initial phases, I would like to initially start learning asp.net MVC without using the entity framework.
Can you give me a link or any idea of using the models to process data without using the entity framework.
So without entity framework you'll be using ADO.NET (See MSDN)
Those classes you mentioned SqlConnection, SqlCommand are part of the ADO.NET framework. The two Microsoft frameworks that build on this are Entity Framework and LinqToSQL.
If you don't want to us either you have to write you own models/classes, and then methods to persist those models into your database. (This is essentially what EF does) You won't get any LINQ or designers etc.
Also, ADO.NET does have a way to create strongly typed datasets. This might help a little.
What you are doing might help you understand whats going on under the covers, but do realize frameworks like Entity-Framework save a lot of time and effort by generating models for you.
I am developing a medium sized ASP.NET project using ASP.NET MVC and Entity Framework. I have developed a 3-tier system by setting up 3 Visual Studio projects and referencing them accordingly:
Presentation -- This is my MVC project and contains all the views and controllers. I deleted the model folder completely from this project as I am moving it to the BO project (see below)
Business Objects (BO) -- This project contains the "meat" of the application, and is where the real heart of the application is located. Here, objects are defined that represent things I'm trying to model in code (User, Facility, Appointment, etc.).
Data Access (DA) - This project is all Entity Framework so far.
The "problem" that I am having is that I am doing a lot of manual one-to-one mapping in the BO. For example, when a User.load() is called, I load the user from EF, then map a number of parameters (firstname, lastname, username, active, etc.) from the EF result to parameters on the object.
I see this as good and bad. Good: it disconnects EF from the project, so if I ever need to use another data store I'm not tied only to EF. Bad: it takes a little more time, because I have to setup each parameter and carefully handle them on Add(), Update(), etc. by implementing my own change tracking.
What do you think of this approach?
it disconnects EF from the project
Which is indeed good.
I am doing a lot of manual one-to-one mapping in the BO
I suggest you take a look at AutoMapper.
I find the book ASP.NET MVC in Action from Manning quite good. The second version, recently released, also has a small chapter about AutoMapper included. It's not in the free sample chapters but you might want to check out the source code (or buy the book of course).
If you are using .Net 4.0 then you should definitely consider creating and using POCO Entities instead of EntityObject which is not only gives you Persistence Ignorance (which you have mentioned) but also you will not need any Mapper in between since you work with POCOs (Plain Old CLR Object) in all layers including your data access.
If you haven't work with EF & POCOs, then this would be a good start:
http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx
If you are using .Net 3.5 SP1 and CANNOT upgrade to 4.0 then like XIII correctly mentioned, AutoMapper will automate your mapping process or you can come up with your own AutoMapper which is nothing more than a simple reflection code.
Can anyone suggest an ASP.NET MVC sample application that uses the ADO.NET Entity Framework against a many relation sql server database?
Most of the sample apps I've seen work against a really simple database with just 2 or 3 tables. I'd like to see the code behind an app that shows more than just the CRUD code to just one table
Thanks for any suggestions!
Rob
You might want to consider an example that has been built using ASP.NET MVC and the Entity Framework using the Northwind database, which is a pretty good representation of a typical business-type database.
Also, if you're not familiar with the web site already, ASP.NET has some great resources for ASP.NET MVC.
Rob Conery StoreFont is a good point to start looking, but it's done with L2S (not much diference anyway)
Source Code here: http://www.codeplex.com/mvcsamples/Release/ProjectReleases.aspx?ReleaseId=18861