I am trying to implement Database first approach using Entity Framework 5.0 but somehow I am not getting it right. I have the following doubts which needs to be cleared.
1.After adding the Ado.Net Entity Data Model a DBContext class 'Model.Context.cs' gets auto-created in the folder under "Model.Context.tt".
Do i need to add DbContext Generator again?(I have found this recommended by others but i could not make out why!)
2.How to scaffold a controller from the edmx files?
Suppose I have an entity, say A (which I want to scaffold to a controller),having one to many relationship with entity B, where will I define this relationship? In the auto-generated model classes from edmx files or do i create classes A & B and define again and then scaffold Model A?
Any help will be very much appreciated. Thank you
Abhatt:
What t4 templates do is generating classes for you and you need to keep them, unless you decide to use another t4 template.
For instance, you may want to design you database but after that decide to use code first to take advantage of code first approach, in that case after designing the database you will add another t4 template named "EF 5.x DbContext Fluent Generator for C#" and that template creates the poco class and all mappings for you.
Whenever you are adding a controller mvc uses scaffolding to create controller's methods and views. However, if you want to have more control on how to generate them, you may install MVCScaffolding from package manager console. Having MVCScaffolding installed, you will be able to customize t4 templates.
For more info check out MVC Scaffolding project on CodePlex:
http://mvcscaffolding.codeplex.com/
also there is another good one:
http://www.codeproject.com/Articles/468777/Code-First-with-Entity-Framework-5-using-MVC4-and
Related
I'm currently working on an ASP.NET project which I've not done before, and I need to use Entity Framework to access a database. I have a database already and following along with this tutorial: https://msdn.microsoft.com/en-gb/data/jj200620
I've managed to get Entity Framework to create the classes for the tables in my database but it has created them all in my Views/Home directory like so:
But from my understanding of MVC these should go in the Models directory? Is it safe to just cut and paste these generated files into Models or am I going to run into problems in the future because it's going to still be trying to use View/Home?
It should be safe to move them to Models. The models are compiled, not deployed as website content, so ASP.NET does not care about their exact location.
You will probably want to update the namespaces of the models, though. I'm guessing that the models were created with a namespace like YourNamespace.Views.Home, and you will want to change it to YourNamespace.Models.
Also make sure to update the namespaces to any references to your models (if you have any). You will get compile errors for any references that you missed EXCEPT for any references in cshtml files.
It would be a lot easier to just delete everything created by EF, and add your ADO.NET Entity Data Model (.edmx file) again into the right folder.
On step 3 of the EF guide in your question, when you add the ADO.NET Entity Data Model, make sure you add it into the Models folder. (Right click on the Models folder, then Add New Item...)
I'm working on an asp.net MVC 3 application which is using Data Models from a compiled library. However I would like to be able to add the following declaration to some data model properties in the compiled dll:
[HiddenInput(DisplayValue = false)]
The problem is that I don't have the source for the DLL and the author doesn't want to introduce a dependency on System.Web.Mvc. Is there a way, using partial classes or something like that, that would allow me add this attribute?
Mark
No, there is no way. Attributes are baked in the metadata of the assembly at compile time and existing classes cannot be modified at runtime. As far as partial classes are concerned they only work within the same assembly.
Also if the authors of this assembly don't want to introduce a dependency in their library with System.Web.Mvc they probably have reasons for this. Obviously, you, as an MVC developer should use view models which are classes specifically tailored to the needs of your views and then map between the domain models (stuff that comes from different libraries, ...) and view models. Then you would pass those view models to the view and not the domain models. Of course your view models will have all the necessary metadata and formatting such as DisplayName, Hidden, ... To ease the mapping between those two classes you could use AutoMapper.
You could map your compiled library Data Models to a set of local models.
If you were to map your compiled library Data Models to your own set of local models you could do what you like.
You can do this manually or look at a tool like AutoMapper.
Add reference to system.web.mvc to your class project.
I've toyed around with the MvcScaffolding project - very nice BTW; however, does anyone know if it supports Model First design scenarios (e.g. EF4 Data Model -> Generate from Database)?
If it does in-fact support Model First scenarios, do you know of any links describing a Model First design scenario?
Thanks...
MvcScaffolding is pretty flexible in terms of what scenarios it's scaffolding will work for. However to support anything other than the default which is code first you may have to tweak the output a little. MvcScaffolding itself doesn't have any constraints around rather you're using model first, code first or whatever. All you have to do is point it to a public class and it will scaffold it.
However, the text templates that ship with MvcScaffolding are designed to generate controller code that interfaces with EF 4.1 code first types, so there would be some tweaking of the generated controller code necessary to support a model first scenario.
I just completed an entire MvcScaffolding implementation using a model first approach. In my case I didn't want to use entity framework 4.1 which is still pre-release. Additionally, I didn't want to hand code all of the types required by my entity model. Rather than tweak the output after the generation was complete, I edited the templates to generate the code exactly the way I wanted it. The end result was I was able to generate, compile and run against a model first entity framework 4.0 implementation.
MvcScaffolding isn't picky about what scenarios it will scaffold code for if you're not afraid to tweak it a little. It is definitely easier to work with code first scenarios as implemented in entity framework 4.1 but with a little work you can get it to support model first scenarios as well.
I'm exploring this too currently. Here is an example using Northwind
http://weblogs.asp.net/scottgu/archive/2010/08/03/using-ef-code-first-with-an-existing-database.aspx
Also looks like there is a gotcha
http://mvcscaffolding.codeplex.com/discussions/247163
Some of my notes and screenshots here:
http://www.programgood.net/2011/03/11/EntityFramework.aspx
Check out LinqConnect at http://www.devart.com/linqconnect/. I haven't used it yet, but I've been researching it over the past week and I think it sounds exciting.
Building an MVC 3 App with Model First and Entity Framework 4.1
Julie Lerman show us how to do it by hand on MSDN
My suggestion: after strongly typed entity classes have been generated under Models folder and real database has been created, use mvcscaffolding:
PM>scaffold Controller MyEntityClass
Yes it does. And very well too.
i.e. I am using it successfully with the new DbContext POCO T4 templates
e.g.
Add your edmx => update from database
Right click the edmx designer
Select "add code generation item"
Select ADO.NET DbContext Generator
This will remove the : ObjectContext derived .designer.cs code, and replace with the DbContext .tt files.
Then scaffold away ! (remembering to pass the -DbContextType into your scaffolding cmds)
I have come up with the steps to do this for a database first scenario. See http://weblogs.asp.net/paullitwin/archive/2011/08/11/use-mvc-scaffolding-in-database-first-mode.aspx
Lets consider default ASP.NET MVC application folder structure, so it's looks like this:
-App_data
-Content
-Controllers
HomeController.cs
-Models
AccountModels.cs
-Scripts
-Views
My question is: Where is the best place to put Entity Framework Data Model (EDMX) file? Is it Models folder? Yes - we know that good solution is to introduce new Project and reference it to MVC application, but lets forget about this now.
For a small project, it should be part of the Model. For a larger product, the repository and the associated model could be in a separate assembly.
Well this is debatable, but i'd vote +1 for the Models folder.
The only other candidate would be App_Data, but this is generally for file-based databases (SQL Server CE .MDF, for example) and files you don't want served by IIS.
As the EDMX is an abstraction of the database, it should go into the Models folder.
If the project gets bigger, you should definetely move your EF Model into another project. To future-proof yourself from this, make your Controllers access the EDMX via Repository/Interfaces, so when you move the DAL over to another project, all you'll have to do is add the reference and add in the using statements.
I would put the EF-model (aka physical model) always in its own assembly or in a "core" assembly outside of main MVC application. The same applies for your business-logic / domain-logic / domain-services / etc. Separate the non-web stuff from the MVC-Web-Application.
This will help you re-use the core part of your app. For example when you need to expose it as a service, a command-line tool, migration-tool, etc.
Because storing this in its own assembly is so easy and takes you a few minutes I highly recommend doing this for each and every tiny app too.
My opinion is that you should create
a separate project for domain objects, datacontracts etc. etc...
Like MyProject.Infrastructure including many folders like
DataContracts, Model, Exceptions etc.
a separate project for DataAccess wich contains the DBContexts and the Repositories, this way you can easily manage migrations later on
I am working on an mvc app that uses some silverlight to supplement a page and instead of having to maintain two separate linq to sql classes I want to add a reference to the main project from the silverlight project but this can't be done through the normal method of just adding a reference, anyone have a workaround?
The normal way to do this is to create a new Silverlight class library project, and use "add as link" to add the existing files from your non-Silverlight project. You can then reference the new project in your main Silverlight project without duplicating any of the files.
Note that if you want to add the LINQ to SQL classes, just add the generated .designer.cs file to the new project--AFAIK dbml files themselves aren't supported in Silverlight projects. You will also need to stub out the L2S attributes present in the classes: ColumnAttribute, FunctionAttribute, and so on.
This may be more trouble than it's worth--if your goal is to communicate with the server using classes generated from a database, you might consider using the Entity Data Model with ADO.NET Data Services (the combination of which is intended for this purpose) instead of LINQ to SQL.