Any Fluent API tutorials that use EF Database-First approach to explain the subject? - entity-framework

There are many tutorials on Fluent API, but they all explain it using Entity Framework Code-First code examples. Since I don't know Code-First, do you know of any Fluent API tutorials that would explain the subject using EF Database-First approach?
Thank you

There are no tutorials which would explain the Fluent API together with Database-First approach because Fluent API is made only for Code-First approach. You don't need the Fluent API if you want to create your model via Database-First.
Fluent API (together with Code-First data annotations and conventions) is a tool to define model details in code, such as string length, if a property is required or the type of relationship - many-to-many, one-to-many, etc. When using Database-First or Model-First the EDMX file has the same purpose - it contains all the details and mapping definitions of your model. Fluent API (+ data annotations and conventions) replaces the EDMX file only when using Code-First.
If you create the model via Database-First or Model-First, you will have an EDMX file representing your model. You can apply the T4 DbContext Generator to this EDMX file. The generated files have two characteristics being different from Code-First:
The generated connection string contains a section refering to the EDMX metadata which will be embedded into your assembly:
connectionString="metadata=res://*/Model.csdl
|res://*/Model.ssdl
|res://*/Model.msl;
..."
The generated context DbContext will have an overridden OnModelCreating method which just throws an exception:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
throw new UnintentionalCodeFirstException();
}
As long as you leave the metadata section in the connection string, EF won't even call OnModelCreating or any code in Fluent API in this method. The metadata section tells EF that your model is DB- or Model-First and that the metadata are defined in the embedded EDMX and not in Fluent API.
However, you can remove the metadata section from the connection string, remove the UnintentionalCodeFirstException and write code with Fluent API in OnModelCreating. You can follow this procedure to create an initial model via Database-First and then build on this initial model for further development with Code-First.
At this point you are not working anymore with Database-First, but Code-First instead and everything you read about Fluent API is valid for you.

There is an interesting post about accomplishing some of the “Database-First” objectives without employing the actual “Database-First” methodology per se.
http://agilenet.wordpress.com/2011/04/11/entity-framework-4-1-rc-with-an-existing-database/
The author uses “Code-First” and “Fluent API”, but disables the auto-generation and seeding of databases and tables.
He shares a sample that shows “how to create an entity model, then manually create your database and then map those entities to your database. Finally it shows using the DatabaseContext to save and retrieve entities”.
The part where he creates a “configuration class for each entity which maps between the entity and the database” is pretty cool. That step replaces the “edmx” files that would be generated when employing a formal “Database-First” approach.

This tutorial in a 6-part Database First tutorial series includes some fluent API examples:
http://www.asp.net/web-forms/tutorials/continuing-with-ef/using-the-entity-framework-and-the-objectdatasource-control-part-3-sorting-and-filtering

Related

What is entity framework designer? Why it is used in the Model-first approach?

I know entity framework designer is used to create the classes of model-first approach and then we create the database by using that class. But in code-first appraoch, it is possible to create the custom classes, within that classes the database is created automatically. Then what is the difference between code-first approach and model-first approach?
Code First is the more modern style of working with Entity Framework. As the name implies, you write the code first and the database model is generated for you, by using Entity Framework Migrations. In this scenario you are not using any graphical tool at all, everything is just pure code.
Model first means creating the abstract database model in the designer. The code is then generated by templates. If you update the model, the code will be regenerated.

Entity Framework Code First model separation from domain

Entity Framework Code First best practice question?
Hi All I am using EF codeFirst 6 on an NTier app.
I have found that poco object that I am using to map to EF are really EntityFramework specific. Let me give you an example
If I want to add a property that is not related to EF in the object ,EF does not like it.
I Read you can put the "NotMapped" attribute however it start making this object difficult to maintain .
Also there might be developers that are not familiar with EF and that will not understand the issue.
My question is it good practice to keep EF Entity Models separate and have a dto to convert to/from to a Domain Model where
a developer can do what he likes with it without interferring with EF Model which is clearly a 1 to 1 with the tables in the database
Any Suggestions?
Your problem could be resolved by using the Fluent API approach instead of the Attribute-based (Annotations) approach. See Entity Framework Fluent API.
You would configure your entity mappings in the DBContext rather than in the entity classes.
From the above linked article:
Specifying Not to Map a CLR Property to a Column in the Database
The following example shows how to specify that a property on a CLR
type is not mapped to a column in the database.
modelBuilder.Entity<Department>().Ignore(t => t.Budget);
that would mean "ignore the Bugdet property in the Department entity."

Generate POCO classes and the mapping for an existing database using Entity Framework

Is it possible to auto generate the POCO classes and the mapping with the database defined separately using Fluent API (instead of annotations) for an existing database? Instead of coding all these entity classes manually, I find it easier if they are auto generated and then I can change them as required if the names are not incorrect (plural or singular) or the some of the relationships are not correctly mapped etc. This will save lot of time for me compared to coding all the entity classes and relationships from scratch and I am not that familiar with the fluent API syntax as well.
Yes, i encourage you to use Entity Framework Power Tools CTP1
Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database.
hope this helps
The Power tools are incredibly slow to generate files. It takes over an hour to work on my companies database (has a lot of tables).
Instead take a look at this visual studio extension http://visualstudiogallery.msdn.microsoft.com/ee4fcff9-0c4c-4179-afd9-7a2fb90f5838
It generates cleaner code, WCF serialisation classes, and includes the database default constraints as part of the POCO ctor.
Disclaimer: I should mention that I am the author of this extension

Can Entity Framework generate the DAL code?

I know that entity framework has a database first approach. Now the question is whether it can generate the DAL (data access layer) code (not the models) for me.
When using a Object Relational Mapper (ORM), you don't typically have CRUD code in the traditional sense. Rather, it abstracts those operations into more object oriented operations.
For example, you don't "insert", you add the model class to the table, then save changes. The ORM automatically generates the SQL needed to make the Object model match the data model.
So my point is, your question displays a basic lack of understanding of how ORM's work and how they relate to data models. You should probably do a little reading.
I'm not sure what you mean specifically by "DAL code", as that's a rather ambiguous term. I would consider your Entity types part of the DAL.
When you use a model-first or database-first approach, the Entity Framework tools can auto-generate a context class from your model .edmx, which will inherit from ObjectContext. It's easy to customize the generated context class with T4 templates by finding one online that already generates from a .edmx, and modifying to your liking.
Code-first development uses the DbContext, which is not typically auto-generated. Please see this post on Scott Gu's blog for more details on this.

EntityFramework withour EDMX

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.