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.
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 new to MVC. I created a ASP.NET MVC5 Login project (UI) using Razor engine that is authentication responsible by using OWIN (VS2013). ViewModels and Data for solution are separated and layered by DLL. I would like to create two separated MVC5 project (UI) into same solution, each one is like a subsystem (eg: Accounting project, Inventory project, etc). Always user has to pass authentication project (Login) first and then according its necessity navigate to Accounting or Inventory subsystem.
My goal is that I could add or remove subsystems when deploying according company negotiation that let it use one or any subsystem.
How can I achieve that?
Every subsystem must be created using a separated ASP.NET MVC5 project template or can be created by a separated DLL?
You can use areas. See http://www.codeguru.com/csharp/.net/net_asp/mvc/article.php/c20227/Using-Areas-in-ASPNET-MVC-Application.htm
What are Areas?
Areas are functionally independent modules of your ASP.NET MVC application that mimic the folder structure and conventions of MVC. Consider the following scenario :
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)
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.