I am fairly new to ASP.NET MVC. I am really confused about the architecture of my project. Let me explain my confusion to you guys:
In my project I have three parts which are know to all of us. These are: controllers, models and views.
Controllers reside inside Controllers folder, views go inside Views folder and models are inside Models folder.
As we all know there are two types of models: data model and business model. The data model has all the data types to be used in the project and the business models do have additional logic related to the project. In addition to it there is going to be a data layer of the application which talks to the database.
I am going to create a class library project for this data layer which will talk to database. Also, Models folder of my MVC project is going to have data models only and I am going to create a different library for business model classes as well.
Now the problem I am facing is this:
Lets say the name of my MVC project is MVCProj, name of data layer project is DataProj and that of business layer project is BusinessProj.
If I define the data types inside Models folder of MVCProj, I have to include its reference in both BusinessProj and DataProj projects. Also, I then have to use BusinesProj classes in my MVCProj. Thus I have to add reference of BusinessProj in MVCProj which results in circular dependency.
I am not sure if the architecture I am envisioning is correct or not. Please help me sort it out.
Arsen's answer already explained very well, but I just wanted to post my own experiences (and that's too long for a comment.)
Your idea of separating Business logic and DataAcess is good. Most projects I worked on are organized in a similar manner.
What I would do in your case is:
1 - Create a project for DataAcess: MVCProj.DataAcess
2 - Create another project only to contain your database Entities: MVCProj.Entities
3 - Add a reference of MVCProj.Entities in your MVCProj.DataAcessproject
4 - Create a project for your business layer: MVCProj.Business:
5 - Add a reference of MVCProj.Entities and MVCProj.DataAcess in your MVCProj.Business project (I'm assuming business layer will call database)
6 - Add a reference of MVCProj.Entities and MVCProj.Business to your MVC project.
See the logic? Each layer is responsible for doing "its job". Now MVC controllers may call business, wich call the database to save the records. All projects share the same Entities.
The "Models" folder on the MVC project is just an example the team provided. In most examples in the web you see people calling the database (Mainly using Entity Framework) directly inside the controllers. This works, but in the long run is very bad to maintain.
Another thing most people do is: You usually don't want to return your database entities in your controllers. Perhaps they include more properties than you will need and etc. In this case you can create what is called a ViewModel. Think of a ViewModel of something like a copy of your Entity class but only with fields relevant to the View. The ViewModels are specific to the MVC project, so they will stay in a folder inside the MVC project. You may call it Models, or ViewModels, your choice.
Not going much further, but with the separation of projects I showed above you can definetly look for a Dependency Injection framework to handle all the creation of instances of the classes for you. :)
Note: It was implied but all projects except the MVC one are just plain old class libraries.
Hope this helps clarify your ideas.
There is no silver bullet in Architecture, all of this is not a must, but depends from the project...
The amount of layers in your application strongly depends on the requirements.
On the one hand additional layer separate the concerns(example: from DataAccess to Business Logic) on the other hand with each level you increase the amount of work, and decrease performance
Regarding your question, it is ok, when one layer depends to another, it is not ok that the third layer depends on the first one...
In your case you choose 3 level, ideally it should look like this
DataAccess, with its data classes in separate project
BusinessLogic, another project, which call data access, and convert result to its data classes
And finally on the model reference BusinessLogic only
I did a write up that I think my help some of your confusion: Entities are not Models.
TL;DR The main source of your confusion here seems to be that you think you need your "data models" (entities) in the Models folder of your MVC project. That's incorrect on two fronts. First, the Models folder is pretty meaningless. You can rename it, remove it, whatever. It doesn't effect your application at all. Second, and as the post I mentioned details, entities are not models. They are, and should be, merely representations of a table structure to give your ORM (Entity Framework, likely) some place to stuff the data it retrieves from the database.
That said, the typical approach is something like the following:
"DAL" class library containing your context and entities. This is where your migrations will go.
A "business" class library that essentially wraps your DAL and provides basically an API that your MVC project can use to get at the data. Depending on the complexity of your app, this is the layer that's most fungible, as you'll often need to draw a fine line between what is "business logic" that might be universally applicable to any application your organization develops vs. "business logic" that is related to the specific application you're developing.
Your MVC project, which will utilize the DAL/Business layer.
In your MVC project then, your Model folder can basically go away, or you can use it for storing view models, instead. It's common, though, to actually create a ViewModels folder for those specifically. However, it's entirely up to you.
One final note. The "business layer", could also just as well be composed of multiple different class libraries. In my organization, for example, we have a library specifically for working with our POS system, a library for connecting to an API we utilize for email lists, a library for working with Elasticsearch, etc. Our web projects just include whatever libraries they need to utilize.
I'm Developing ASP.NET MVC Web Application project, and I'm using Entity Framework Database First Approach, So I would like to make validations on generated model classes, I know if i make validations on them directly, then my model validations will be overwritten every time my domain models are regenerated.
So I made a research, and found two approaches to use for this scenario:
1- Using buddy classes (How to add validation to my POCO(template) classes).
2- Using ViewModels and Auto-mapping them to my Entities (Designing an MVC repository using ViewModels
I see some sort of redundant code in these two methods, so, my question is:
Which one of the two approaches is best to flow?
1) This is the correct solution for adding validation metadata for the Entity Framework objects. The validation will be triggered automatically by EF before calling SaveChanges()
2) This is an aproach for creating Data Transfer Objects from your EF objects. You normally do this when you want to return the objects to the client (like in JSON format) - and you don't want to expose all the EF specific properties (like navigation properties, primary keys etc)
I have a database name CostDB on a SQLserver. I need to create a page (ASP.Net MVC 4) with a simple dropdown list (i.e. Company Name) which will be directly bind to the Company column of DESE table from the CostDB database.
I am lost after looking at all tutorials and ASP.Net MVC4's own tutorials that what way to start? There are different ways of code first, model first etc. I already have the database. Do I need to create a Model first in this case? If so does it have to be exact name match from the DB table names? Or do I generate the model from the database?Which functions would I need to create if I need to show data in the dropdownlist on page load? Most importantly what is the order to create an MVC application for an existing DB. Among M,V,C, what to create first?
Completely new to ASP.Net MVC 4. Already did go through MVCMovies tutorial but with no luck. Any suggestion would be really appreciated.
I think the best answer is this: Whatever you are comfortable with and what works for you. There are tons of different approaches to development, and variations of each of those approaches. I tend to lean towards database first, as I don't have as much experience in code first.
Since you already have a database created, I think the easiest approach for your method would be to generate an EDMX off of your existing structure and go from there. Once you have the EDMX built and all the appropriate files referenced, it should be easy. Just populate a list from your EF model, toss it into the ViewBag, and then populate your control(s).
Here is a good link on how to do this. Populate #Html.DropDownList with a List using MVC
I would highly recommend PluralSight for learning any type of development, one of the best sites I have ever used. Best of luck!
I've been playing about with the Entity 4 framework lately and it's pretty nifty. I've setup a class called Customer.cs with some properties like Name, Address etc. I also have a class called StoreEntities.cs which binds these back to the database through DbSet. It works fine and I can pull all my customers from the database.
The problem is every tutorial I come across on the internet generates their classes by hand. What I mean is, they all say something like "Now I'm going to make a new class called Orders with the following properties" and then proceed to write it out. That might be ok if I was starting a new project, but I'm porting over my old website so I have upwards of 20 tables in my database. If I go through and write all these out by hand I'm going to be there all week :D
Plus I'm not sure what would happen if I made some changes to the database (since I would have to go back through and update all my classes by hand).
I was hoping EF4 would have something similar to a Class Diagram, where I can point it at my database and have it generate a bunch of classes for me based on that.
I'm a little lost on this. Am I going about this the right way?
You should take a look at the ADO.NET C# POCO Entity Generator. With that you should be able to generate your model from your existing database and T4 templates will generate your POCO classes based on your databases tables, etc.
Here is a link to MSDN that explains how to Update Model from Database using the Update Model Wizard.
There are two ways to achieve what you want. Both start from adding new item to your project. In the "Add new item" window select "ADO.NET Entity Data Model". There you will have two options. One to generate your model from existing database and second to create model manualy in designer. If you choose first one you can simply drag and drop tables from server explorer to design surface and all your entities and their relations will be generated for you automaticaly. Also you can modify that generated model later.
I would generate entity framework model of my whole database or do it scenario based with 2-5 tables entity model generation? What is the best thing to do
Generate only the tables needed by the application. Then write wrappers around it based on scenario.