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
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 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
This question has been asked a few times in SO but nothing helped so far in my case.
To an existing MVC project I added a model generated from a database (using database first). Now I would like to add a new API controller. However, neither my new model classes nor my data context class show up in "Add Controller" dialog:
made sure I recompiled my dll
restarted VS (2010)
deleted AssemblyInfo.cs (as suggested in another SO post)
checked with ILSpy to make sure models are in and have an Id
My workaround is to put my models in another dll. However, I think that shouldn't be necessary...
Could it be as simple as a namespace or reference issue.
If they are in different projects then the controller project will eed to reference the respository project.
Can you get to the models by using the full namespace path - you made just need to add a suitable using in the class; typing CTRL+. will give you suggestions.
Hope that helps a little.
I find this site is very interesting and very helpful. I came up with this doubt while programming a project in asp.net mvc. I had to remove few columns from a view which I was using to pull data from the database back to my presentation layer. After removing those columns, I build my project and there were no errors. When I ran it, my project broke with error saying missing related columns as Entity was not changed.
But, my question is that is it necessary that every time I need to update my entity model?. What if I deploy my project in production and then had to remove one column from the view? It will be a hell of task for me If I had to update model, build and deploy it back again on production. Is there a simple solution for this?? thanks for your help
You have to update the entity model every time the database structure changes, what you need to do is to decouple the EF model from the MVC project, if you don't what to work with Ioc, a simpler approach whould be to place the EF model in a separate assembly, when the database changes, rebuild the assembly and deploy it on the server, this way you don't need to rebuild the entire MVC.
I have looked around but cannot find anything that answered this particular question related to file/project structure.
I have an MVC3 site using entity framework. It follows a basic generic repository pattern using StructureMap to handle dependency resolution.
My question is, how do I lay the projects out? taking in mind I may want to expose the database to another application down the track.
Currently I have:
mySite.Web -- MVC Project also has all the dependency resolution
mySite.Web.Data -- EntityFramwork CodeFirst, Repository pattern
mySite.Web.Tests -- Tests... :-)
Should I be moving my EntityFramwork models to there own project? if so where would things like my EntityContextFactory go?
Thanks
I have the same problem - How to setup a new mvc project?
My research and help for other user is: A good structure approach is the Domain Driven Design for MVC Architectures.
good blog post for DDD
my new project structure will look something like this:
Presentation.Web (Controller, Views, ModelViews..)
Presentation.Web.Utils (Helper and Extensions..)
Presentation.Web.Tests (Moq..)
BusinessDomain.Services (Business Service for DI )
BusinessDomain.Models (EF Models..)
BusinessDomain.Tests (Moq..)
CrossCutting.Common (Const, Resources, Exception Msg...)
Infrastructure.Configuration (IoC Bootstrapper, ApplicationConfiguration,ContainerExtensions..)
Infrastructure.DataSource (DbContext, Repositorys..)
Infrastructure.Tests (Moq..)
I would create a new project called mySite.Domain and possibly create a entities folder in that project and place them in there.
I'd only store entities in the Domain and keep all repositories, your dbcontext and entity contextfactory in your Data project.
Here are some sample projects you could have a look at (credit to authors):
http://myfinance.codeplex.com/
https://github.com/darind/samplemvc
This is largely subjective though.
No this structure is good.you may move pattern repository to mySite.Web or create another class library project for it but it is not necessary.