Can a Model First approach in MVC be implemented by avoiding the UML designer file? In my previous company Entity Model was written in a Xaml file. Then we used to run a T4 template tool and then get an Edmx file by choosing Generate views option. This would create class file and SQL scripts for procedures, Table Valued Functions which we later execute in SQL server to create database.
I am confused whether its code first or model first approach as we had not used any diagram to create entity relation.
This is model first.
But IMO "model first" is a misnomer making it more confusing than it should. In fact, it's "mapping first". An object-relational mapper (ORM), like Entity Framework, always deals with three main components --database, object-oriented code and the mapping between these two. Any of these three parts can be created first.
The other flavors are "database first": first the database, then the mapping (edmx) then the code (running t4 templates) and "code first: first the code, then the mapping (conventions, data annotations, and/or fluent) then the database (migrations).
Related
What are the benefits of using ADO.Net Entity Model and EF?
Can we use both of them together in a project. I came across an example where, the user had used both edmx and ef for his application. I am not sure what is the purpose of that.
Thanks
Edmx artifact (either in the form of a file on the disk for Model First and Database First approaches or being generated by the EF runtime - Code First approach) describes your model, your database and the mapping between these. At the moment EF always needs it to work. The only nuance is that for CodeFirst applications (or, in general, applications using DbContext) this file is generated on the fly from your classes and you don't deal with it directly while in case of Model First/Database First where you use the ObjectContext the file is on your disk and (usually) is split and embedded in your assembly.
EDIT
EF6 no longer creates and uses artifacts internally (at least for CSDL and SSDL parts). However you can still dump the model in form of EDMX using EdmxWriter.WriteEdmx
I like the Code First approach, but often I would prefer a visual model. The edmx model is a lot friendlier and neater for modelling a 'data model' than VS class diagrams, so it would be nice to generate an edmx from the code first POCOs and start round trip engineering, seeing as it is possible to generate POCOs from the edmx model.
You can use this vs extension to generate edmx diagram from code first dbContext, its read only as of now (extension is only in beta) http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d
If you generate a database from your POCOs, you can then add a new EF item to your project and have it generate the model from the database. It's a little roundabout but it works well. I use it to check that the relations in code first models actually match what I intended.
I'm trying to figure out what the best way to go would be for Entity Framework code generation with a "database first" approach. I want the complete master description of the model to be the actual database schema with annotations stored in database in tables or extended properties. Not interested in a model first or code first approach. Not opposed to writing custom code to implement if it will yield the highest quality solution. Here are some ideas:
(1) Generate EDMX from the database. Use custom code to add annotations to the EDMX regarding uniqueness and other constraints that are not currently built in to EF. Use T4 templates to generate code from the EDMX.
(2) Write a custom tool that generates "code first" classes from the database. No EDMX files in the solution.
(3) Something else?
It seems like #1 requires deeper knowledge of EF and more actual work than #2, which I am now opposed to if there are significant benefits.
Any advice?
Well, nothing is easier than just dragging the tables from the server explorer to the edmx designer surface. That is how I do it. I don't do any customizations to the model so I can just delete parts of it an regenerate.
You can import the model from your database with EF. Right-click on the EF designer and choose "update model from database" option.
If you want a little more you can try http://radarc.net . It's a code generation tool which creates scaffolding and CRUDs. It uses T4 templates and code first so you can customize the way it generates code.
I'm trying to kick off a project needing table-per-hierachy. I've done this in the past with NHibernate, but we want to avoid having to hand edit XML mapping files - so are trying to use Entity Framework and it's Designer.
I've been following this example online:
http://mosesofegypt.net/post/Inheritance-and-Associations-with-Entity-Framework-Part-1.aspx
When trying to select a Table from the "<Add Table or View>" dropdown, I can't select any tables, instead the list shows "(Empty)".
The only deviation I've made from the tutorial is that I didn't generate the Person table off the sample database, as far as I can tell this shouldn't make a difference (we want to generate the DB off the model, not vice versa).
Not sure what criteria a table needs to meet to be eligible to add a discriminator to...
If you need to generate DB from the model you cannot see any table in mapping because both mapping and information about tables is generated when you generate the database. EDMX has quite complex structure (much more complex than very easy hbm files for NHibernate). The complexity is even worse because EDMX doesn't have anything implicit - everything must be described and it must be described three times.
EDMX consists of three parts:
CSDL - conceptual model you see in the designer (classes)
SSDL - database description - this can be browsed in model browser but it is read-only
MSL - mapping between SSDL and MSL (that is what you are trying to edit in that window).
When you are going to use model-first (draw entities in designer and generate database) you define only CSDL and everything else is generated with SQL for the database. You will also probably need another template / workflow for DB generation because I guess it will by default use Table-per-type inheritance. Check Database generation power pack - it should contain template for TPH.
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.