I want to know your opinion.
In scenario, where only stored procedures are used for data manipulation - is better to use standard ADO.NET or Entity Framework 5.
The only (and main) reason for using EF are strongly typed classes (generated complex classes), that can be used as a model in ASP.NET MVC 4. Updating complex types could be simpler in EF compare to ADO.NET.
Reason for using ADO.NET is making communication with database more simply.
Thank you for your opinion.
You could also look at e.g. Dapper-Dot-Net (or some of the other "micro-ORM") which is based off "raw" ADO.NET, but also offers conversion to nice .NET objects (the main EF benefit in your case, I believe) from stored procedure results
Related
I am using an existing database and my normal method is to add a new Entity Data Model and point it to the existing database. If I was to use the EF power tools and reverse engineer to make it 'code first' style what is the advantage of this ?
Both are classes that inherit from DbContext right ? So can someone explain to me what an advantage might be working with the code base over time if I was to use the EF power tools reverse engineer tool instead ?
Code First to an existing database generates your model (at runtime) from your C# classes. Database First stores the model inside of an .edmx file and generates your classes (at design time).
The video Entity Framework Development Workflows gives a good overview. Ultimately, it comes down to whether you want to maintain your model using a designer surface or using C# classes.
It is also worth mentioning that, if you want to use Code First Migrations, you have to use Code First since it currently doesn't work with Database First.
Does anyone know why LinqPad cannot autogenerate an Entity Framework context object (like it does with Linq-to-SQL)? It seems I have to create an assembly containing an EF context and then reference the assembly in LinqPad. But I don't need to do this with L2S.
Thanks very much.
LINQPad uses LINQ-to-SQL for automatic data contexts because it's lighter and faster. LINQ-to-SQL also generates better SQL in many cases and allows arbitrary functions in the final projection.
It wouldn't be hard, in principle, to write a driver for Entity Framework. The reason it isn't present as an option is lack of demand.
If you wanted, you could implement EF support seamlessly as a third-party driver. The only tricky thing to implement is supporting every version of EF.
We are about to start using EF as our ORM. We have our own MetaData representing the databse stracture and we will generate whatever we need off of that.
We are wondering whether to use the "old" EDMX approace, or to use the new EDMX free approach (wiht DbSet and DbContext). As we do our own code/edmx generation it seems odd to generate an EDMX and then generate objects and context off of it.
The thing is I don't see much talk about about the EDMX free approach. Is it being used by anyone? Can someone with experience share their impressions? Are there known limitations? Are there pros and cons?
Asher
Are you asking if anybody is using code-first? :) By checking the number of questions in entity-framework-4.1 and code-first and ef-code-first I guess people are using it a lot. There were several questions about code-first x non code-first. Some of I answered:
EF POCO code only VS EF POCO with Entity Data Model
EF Model First or Code First Approach?
EF 4.1 Code-first vs Model/Database-first
Generally there are four approaches:
Model first (database generated from EDMX)
Database first (EDMX generated from database)
Code first (database generated from code mapping)
Database first with code mapping (code mapping manually created for existing database or manually updated mapping generated by EF Power Tools CTP)
Selection of the approach usually depends on the way how you want to develop application (as described in linked answers). It also depends if you want to use ObjectContext API or DbContext API. The former one is usually used with first two approaches (but the secret is it should work with code-first as well) the later one with all of them.
Code first has some limitations - it doesn't support all mapping features EDMX does for example:
Stored procedures mapping (it doesn't mean you cannot execute SP when using code first)
SQL functions mapping
Advanced EDMX features like defining queries, query views, model defined functions
etc.
What I don't understand is why are you trying to combine your code generation tool with EF. Either use your stuff or use EF's stuff. You will avoid complications and incompatibilities.
How do I specify Xml or just in-memory storge for Entity Framework models? The connection string requires a provider (usually a SQL provider string). But it won't let me omit the provider.
I realize I could completely throw away the designer generated objects and go pure POCO, but then I'd have to implement my own serialization layer (could do that, but it's overkill for the tiny project I'm working on).
Is there built-in support in EF 4.0 for this that I'm missing or do I just need to go the pure POCO route and discard the designer experience entirely :(
If you want to store data in Xml or memory you should probably not use EF. EF is designed to work with relational databases.
See also: Entity Framework with XML Files
For storing data in memory use System.Runtime.Caching
For storing data in xml files see: http://msdotnetsupport.blogspot.com/2007/04/reading-and-writing-xml-files-using-c.html
This is a good way to do what you're probably thinking.
Use a SQLite db as the backing store. That way you get you're single local file and you can still use almost all of EF.
http://dotnet.dzone.com/news/sqlite-entity-framework-4
I have not hardly touched EF4, but I've used Linq to sql quite a lot. I would like to start into one of the EF templates but I have no idea what situations make sense for each or what their intent was.
I have the following possibilities:
Data templates
ADO.NET Entity Data Model
Service-based Database (is this even related to EF?
Code templates (I am familiar with T4)
ADO.NET EntityObject Generator
ADO.NET Self-Tracking Entity Generator
Online Templates
ADO.NET C# POCO Entity Generator
I have no idea what situations make
sense for each or what their intent
was
Not meaning to sound rude, but did you have a look on MSDN/ASP.NET to find out? There is plenty of information around. And there is a lot to each of those templates, more than i can go into here. There is a MSDN page for each of these.
That being said, i'll give you a quick summary, so people who stumble here have some info.
ADO.NET Entity Data Model
This is the file you create to use Entity Framework as your ORM, and it is mandatory for using EF. You need this before you use any of the others. You can create your EDM with a number of different approaches, including database-first (generate from DB), code-first, model-first, etc.
Service-based Database
I have never heard of this term, and given i've been working with EF a lot lately (and reading), i doubt this will be related to EF.
ADO.NET EntityObject Generator
Generates classes for entities which inherit from the EntityObject class. Identical to the default EF code generator, except instead of putting output code into the Model.edmx.designer.cs (default) file, the code gets put into seperate files. I personally don't see any benefit in this template.
ADO.NET Self-Tracking Entity Generator
Generates classes for entities when you want to develop N-Tier applications (ie if you wanted to allow a WCF/Silverlight app to work with your model). Entities are setup to be 'trackable' by the EF Graph, in order to handle persistence operations from various applications.
ADO.NET C# POCO Entity Generator
My favourite. :) Generates classes for entities which inherit from nothing. They have no idea that they are being used for persistence. Use this for applications when you want persistence-ignorance, testability and loose-coupling of your domain/persistence layers.