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
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 planning to create a web application using MVC 4 Single page application and I will use database first approach. And I'm using the default Sql Server LocalDB (with the login/authentication tables).
Where should I put the edmx file? Under the Model folder? What if I want to have a service layer/repository layer.
BTW, the default template of SPA create two classes for each model, for example TodoList.cs and TodoListDto.cs. Why and is there any better design to avoid two classes?
I like to start by creating a {DataLayer}-Project.
Add the EDMX file to your {DataLayer}-Project
Add a references (under references) from your main project to your {DataLayer}-Project
add using {DataLayer}-Project; in every file that makes reference to your Entities
When my project achieves optimum maturity, I change my {DataLayer}-Project into a service.
I've got an ASP.NET MVC 4 site with MSSQL database generated by code first approach. I want to use this database in another project. This project should crawl several tables from db, update them and send notification to users.
What is the best way to add existing database from the first project to the second project? I'm thinking about generating edmx by database, but this approach doesn't seem good enough.
You would be best moving the EF code and Entities into their own library, and then having your two different projects (Web and Windows Service) have a reference to that library.
Then, if and when your database structure or entities change, you only need to do this in one place.
If the second project is not going to modify the structure of the database, then I would use a data-first approach in your second project.
You can use codefirst mapping without problem on existing database. So simple reference assembly with datacontext in other project and it will work. (Don't forget set connection string in config file of other project)
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.
is there any particular directory that i should put my code into in an asp.net mvc project
i have some extentions to the HtmlHelper class. Right now i have it sitting in the Content folder. is this correct? is there a better soluiton?
I usually create a separate project (or projects) for my own code, including my data layer, as class libraries. I then reference the libraries in my MVC web site.
you can put code wherever you want, but typically you want things organised. heres how i do it:
2 assemblies
MyProject.Domain
this contains all my domain code; business logic and entities
MyProject.Web
this contains controller code, views and assets like css/images
Your HtmlHelpers belong in the .Web project because they are mvc related (nothing to do with the domain). You probably want a new folder called Helpers or Extentions. Its really up to you, the key point is to decide where something belongs and to namespace it accordingly
I agree with what everyone else said, here's how one of my solutions would look like:
1- MyProject.WebUI
2- MyProject.DomainModel
3- MyProject.Test
4- MyProject.Extensions
This extensions project is new to me (actually since I knew about extension methods). It usually concludes sub-folders describing what the extension methods are used for, for your particular case, the folder name would be HtmlHelpers. I then reference this project (or its output library when using elsewhere). HTH
If you are going to re-use the same HTMLHelper extensions in different ASP.NET MVC projects, I'd suggest putting them in a class library which is completely seperate from your project.