I am working on an asp.net MVC 3 project as a team member. This project has some folders like repositories, infrastructure, Datalayer, services, providers and ViewModels. When I create an asp.net MVC 3 application, It has only 5 folders views, models, controllers, contents and scripts. Why these additional folders are created. I read in an article (http://msdn.microsoft.com/en-us/library/aa973811.aspx) that service is an object that performs a distinct part of the application functionality and Repositories are strongly typed classes that provide create/read/update/delete for objects. what is difference between service and repository. If I name these folders to something else will it make any difference. What type of classes should go in below folder classes:
repositories
infrastructure
Datalayer
services
providers
ViewModels
I read somewhere that repository is a pattern what does it mean? Also are services also a pattern?
Please suggest
Regards,
Asif Hameed
It is most likely something added by the software architect in your project. I would guess that Datalayer and repositories are there to help out with implementing a layered architecture. Perhaps something like:
Datalayer (NHibernate or some other ORM or whatever)
Repositories (Classes used for CRUD stuff)
Application (Your MVC application, where controllers use repositories to fetch data, then put this data in the models, then sending the models to the views where the data is displayed)
Something like this, I guess, would be a typical way to use MVC3. Hope it helped :)
Related
Is it possible to add EF6 to a razor class library ? The goal is to have many components shared by other BLAZOR projects, but a lot of these controls require access to the database, which is the same for all the projects inside this solution. Also, I assume that the db access will be via a controller since it is not possible to inject as a service. Is this correct ?
Is it possible to add EF6 to a razor class library ?
Yes but you would immediately restrict that library ro Blazor Server side.
a lot of these controls require access to the database
That is not a great architecture
I assume that the db access will be via a controller
Not necessary with server-side, you can inject a DbContext into your pages and components
When you have components that depend strongly on your Entity classes and business logic then a Razor Class Library is maybe not the best choice.
When you do want this, create a specific layer with storage-agnostic models and interfaces for services. It's the 2 layers at the core in the Onion architecture.
Your component can depend on the interfaces and the main app can implement them.
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 new to ASP.NET MVC and inherited a project that uses the technology.
Such Web project contains three folders: Views, Controllers and Model. As I understand it, the Model contains in fact your domain / business logic and is called by your controllers. The controllers themselves act as delegators between Views and Model.
Now, in a typical layered architecture, there should be no references in any project to the Web/UI project.
I find this quite confusing:
-> The UI contains the Model, which is - in an ideal world - based on "Domain Driven Design"-principles.
-> The layers on top of the UI (Services and DataAccess) cannot have a reference to the UI
How can you write efficient services and dataaccess layers if they do not know your model?
What am I missing here? Is the Web.Model different from "DDD" and should I still have a separate BL project? If that is the case, then what is the Web.Model supposed to contain?
I view the Model as a concept. You can have a completely separate project containing your Domain (your entities, your services etc.) and reference that in your "UI" project. In this scenario this will be your "Model".
This is what I typically do, In my Models folder I keep "ViewModels", which I use for Binding/Validation (for the UI).
For example, If I have an Employee but I don't necessary want to use all its properties (or for that matter different properties), I will create an EmployeeViewModel adjust it the way I want, I'll add validation (if required) and I'll pass it to my View.
This is by no means, "the right way"/"only way", but It worked for me in the past, and I thought I'll share (also, I'm pretty terrible in explanations, so I really hope this post makes sense, in case it doesn't or clarifications are needed - please let me know).
You necessarily do not need to have your model in the same project. You can ofcourse have those in different layers.
This is how i usually setup my projects
1) UI Project - This is an MVC Web application type project where i will have my controllers and it's views and other UI related stuff
2) Business Entities - This will be a class library type project where i will define my domain objects ( Ex : Customer). This mostly looks similar to how my DB schema looks like. These are usually just POCO's which represent my domain modal ( I use this for the CodeFirst Database generation).
3) Data Access - This will be another class library type project which has the data access classes. Usually my repository class/interfaces, my DBContext class and other data access classes will be in this project.
4) Tests - Unit tests for the project
Business Entities project has been added as a reference to the Data Access Project so that i can use those classes in my Data access code.
Business Entities and Data Access Projects are added as references in UI Project. I would call the data access methods from my Controllers/ Service classes.
You may also add a Service/Business logic layer between your controller's and Data access layer as needed.
I have few ViewModel classes also inside my UI project ViewModels folder. I use this for some screens where i have to show data from multiple domain objects. I have a mapping/service class which maps the domain object to view model object. If your project is bifg, you may keep this as a serperate project under the same solution
Views Contain your HTML Layouts
Controllers do the heavy lifting of getting data from the models or the models themselves and passing them to the Views.
Models are used to do actions for your BL or fetch data.
Tip : You can use a EntityFramework ( i'm recommending it because it's easy to get started with ) to fetch your data and it's dead simple to setup thus eliminating your DAL and saving you time from writing everything yourself.
Services : you can have controllers that return XML/JSON (other format?) by converting the data you have got from the DB to XML/JSON and returning that instead of a view.
Take a look at MVC 4 WebApi for more details,Note that you can pretty much the same thing with mvc 3 too
Also refer to asp.net/mvc site for tutorials to get you started, they are really useful.
Ok it seems my project setup could use some improvments.
I currently have:
1. ASP.NET MVC3 Web project
2. NHibernate project with Repositories/Mappings and some session code.
3. Entities (models used in nhibernate like User.cs)
4. Interfaces (like IUser, IRepository<IUser>, IUserRepository...)
5. Common (UserService, ..)
Now the issue is that I my nhibernate models now need to implement IUser, which I don't like, but I was forced to do this since my IRepository is generic, and I could use IRepository<User> since User is in another project, so I had to create an interface and do IRepository<IUser>
I will never need to have another implemention of User, so this is bugging me.
How can I fix this while keeping things seperate so I can swap out my ORM?
The IUser interface must be defined in the Entities layer if your entities implement it, not in the Interfaces layer. Also I would probably rename this generic Interfaces layer to Repositories or AbstractRepositories or something. Also I would rename the Common layer to Services if it contains services aggregating your repositories.
So the picture could be:
ASP.NET MVC3 Web project
NHibernate project with Repositories/Mappings and some session code.
Domain Entities (models used in nhibernate like User.cs and implementing domain interfaces like IUser)
Repositories (like IRepository<IUser>, IUserRepository...)
Services (UserService, ..)
I think you should approach this problem from Domain Driven Design perspective. Domain should be persistent-ignorant. Proper implementation of DDD repository is a key here. Repository interface is specific, business-focused, not generic. Repository implementation encapsulates all the data access technicalities (ORM). Please take a look a this answer and these 2 articles:
How to write a repository
DDD: The Generic Repository
Your entities should be concrete types, not interfaces. Although you may never need to swap your ORM (as Ladislav is saying in comments), you should design it as if you will need to swap it. This mindset will really help you achieve persistence ignorance.
I have an MVC solution setup like this, with three 'projects'.
Web (MVC Project, Views, Controllers, ViewModels)
Models (Domain Objects)
Persistence (nHibernate Mapping, SessionFactory)
I need to begin building the repositories, and was going to start with the Authentication Model. Basically following the default MVC template, have an IMembershipService and an IFormsAuthenticationService and related classes (using custom code, not built in authentication providers).
My question is ...where should this go? My Repositories will need access to both my Domain objects and my Persistence Layer. However I keep reading that any kind of 'coupling' means it is a bad design. So I am hesitant to create a fourth project for the Repositories/Services that references the Models/Persistence ...but I can't really find any other way to do it logically.
This is very subjective.
Do what makes sense to you and your team.
I throw them in with the rest of my Repositories. I mean a User is pretty central to any application right? Does a User own anything? If so then isn't he an root?
Repositories are part of the domain.
Tension will always exist between reducing assembly references and minimizing number of projects. That is, you can make each assembly reference fewer dependencies by breaking up functionality into more fine-grained assemblies; however, excessive division of a project into many assemblies requires more effort to manage.
Another point worth mentioning is that authentication has a couple sides to it. One is managing the model around Users, Roles, Permissions, etc. - this is a domain concern. The other is interfacing with the context of execution (whether this is an ASP.Net app, WinForms, etc.) - this is an infrastructure concern. Consequently, I end up with a small service in my MVC project or WinForms project that performs functions like setting Forms Authentication cookies, or setting the current thread principal, etc.
The Separated interface pattern says that your models and repository interfaces should be in a seperate assembly, apart from the GUI and the actual repository implementation. This is to be able to switch implementations later on and to be able to simplify testing.
I would have no problem with putting the interfaces along with the repository interfaces and the actual implementation in the mvc project or the repository project. It's quite easy to move stuff later on if you use a IoC container.