What is the difference between EF POCO and EF Code First?
If I am starting with just POCOs can I use EF with them?
If you use EF code first you have POCO objects and the database is created with code from the DbContext class. You get no visual designer when using code first.
You can also use POCOs for “ordinary” EF but then your database will be handled by an edmx file and a visual designer.
Wich approach you use is up to you as a developer, but my opinion is that the code first alternative is cleaner than the edmx solution.
Just a supplement: you can use Code First in case your database exist first too. In this case you are using POCO classes too and you are describing all the relationships via Fluent API or Data Annotation. This approach is called Reverse Engineering.
Generally, POCO is some simple object, exactly "Plain Old CLR Object" and Code First is the approach that is working with the POCOs.
Related
I have been unable to find a good reference for all useful data annotations that can be used on Entity Framework code-first models. I've found a Code First Data Annotations article and the System.ComponentModel.DataAnnotations Namespace reference and the System.ComponentModel.DataAnnotations.Schema Namespace reference but there are a few that can be used from the System.ComponentModel namespace (i.e. the commonly used DisplayName annotation) for your data model, but not all of them.
Is there a better reference for what is and is not useful for EF data model annotations? I think part of the answer also involves which annotations are actually used today by the default EF templates. I just wrote my own little extension that gets the Display(Description) annoations so I can use that in my HTML title tags (and thus by handy things like jQueryUI's tooltips) so I suppose it's possible to "use" a ton of annotations if you extract them yourself. But there are many used by EF to figure out your model schema, too. It's just really aggravating to bounce back and forth between the various references figuring out which annotations you can pick from. I should just quit whining and publish my own little cheat sheet huh :) But in the interests of DRY I'm hoping that already exists somewhere!
Actually there is no complete and updated reference for Last version of EF which cover all aspects of the Code first approach.You have to involve in couple of things such as text book on this issue or videos,but the best way I recommend you to do is,to decompile resources or assemblies in Visual studio and Resharper tools and try to figure out by codes.
Update:EF Code First Data Annotations are limited by count(about 16) and if you want to have more control over your Data Model creating you have to use EF Code First Fluent API way to do it.Here are some good references:
"Configuring/Mapping Properties and Types with the Fluent API"
"Entity Framework Tutorial"
All tutorials I can find is with database or entity framework. I just want a simple class as model with field creation and update from the view and using .aspx template.
Can somebody give me as simplest example as possible or point me an article on the web I've bee googling all day long without finding any.
Simply use an EF Code First tutorial and remove the calls to DbContext - without DbContext, the entities are simply POCOs. Replace those calls with however you plan to persist/read your data.
I have an asp.net web forms application that uses linq 2 sql. A lot of the controls are databound to linq datasource controls.
I want to clean up this application so I can easily use html5's offline functionality.
I thought I should probably move my linq 2 sql statements from code behind to classes and then call to the class. Not sure?
What I would like to do, is have a clean separation and since MS is no longer promoting linq 2 sql, I would like to move to linq 2 entities.
Eventually, a while from now, I would like to convert this app into mvc, but one step at a time.
Would it be better to just make separate data classes for each form or just create database first linq to entity classes?
Thanks,
Sheri
I would recommend reviewing the Repository Pattern suggestions here. I've been using the Repository Pattern with LINQ-to-SQL and ASP.NET MVC since 2009, and it has been very good for me for managing my data interactions, maintaining separation of concerns, and, especially, testing.
I'm attempting to setup Entity Framework using Code First on an existing database. The database isnt in great shape (poor naming convention and some constraints are needed). The application I'm building is an MVC app. I have a "Model", "Repository", and "Web" (mvc) tiers.
To setup EF and map my model objects (POCO objects), is it required that I match my objects to database tables? Can I, instead, use my own stored procedures for CRUD operations? Would it help if I use WCF data services?
I'm planning on using fluent configurations to map my objects, but having some issues due to the database schema. I'm know considering redesigning the database just to get EF to map correctly. Any suggestions would be greatly appreciated!!
Looks awfully similar to this question:
Does Entity Framework Code First support stored procedures?
The answers there may be helpful to you, as well as the discussion surrounding how Code First and Stored Procedures don't make a whole lot of sense.
Wow, Julie Lerman answered!
Yes, it's possible, but not particularly easy. In particular, you must call context.Database.SqlQuery<T>() where T is the entity type you want to return, and your SQL must match up to that entity type. Otherwise, you will have to massage a result set into a type.
In general, you will have to do most of this manually, although you could probably figure out a T4 template to generate it for you, or maybe use some other tool like CodeSmith.
My question is pretty simple: is it a good practice to place the .edmx file in the model folder in a Web application of an MVC3 project?
my answer is pretty simple, do not mess up presentation layer (Whole MVC application) with data access logic and data modeling.
Have at minimum 4 projects in your Visual Studio Solution, from bottom to the top:
1 - ProjectName.Interfaces (Class library, entities's interfaces);
2 - ProjectName.DAL (Class library, the only one allowed to even know the EF is used, the POCO entities implement the interfaces of project 1 using another file where you redeclare same objects using partial classes...);
3 - ProjectName.BL (Class library, Business logic, references the two projects above 1 and 2);
4 - ProjectName.Web (ASP.NET MVC application, Presentation Layer, references two projects 1 and 3 but NOT 2);
this to simplify things of course, based on my experience this is a solid design, a bit overkilling for very small projects but pays off in the long term.
in my view, the M of MVC, Model, is NOT the data model, is not the EF, is not there to do ORM bound to the specific database engine.
this answer is subjective of course and is based on my personal experience ;-)
I agree with Davide here completely I just want to add that you should also consider using the POCO templates to generate poco objects and not return entity framework objects to another layer because it then puts a dependency on the entity framework.
At some inevitable point if you don't pluck this out into a separate project, your direct data access code ends up thrown into your web code. I see it all the time (and we've all been guilty of it at some time)
I don't think this matters much.
I use CodeFirst, so my DbContext class goes to the Model folder.
Really, the EDMX is there just for the code generation, beyond that it does not do much, its not deployed/published to your server, etc. So where it stays isn't important. You could create another folder for it EDMX if you want, or put it in Model as you asked.