I want to asp.net mvc project using n-tier architecture. I have Confused in that issue;
I have 4 tiers that are BLL, DAL,Entities and WebUI. WebUI tier is a asp.net mvc project. I added data model into entities tier. In DAL, I create some classes about crud opparations using entity framework. Finally I serve this classes as repositories on BLL. BLL knows DAL and entities tiers, DAL knows entites tier and WebUI is only knows BLL. In WebUI, I can access repositories where is into BLL.
But this repositories' return values are entity classes. I have to give a reference from entities to WebUI tier. I don't want that WebUI accesses databese directly. It should access database using repositories inside BLL.
What should I do? I want to do right thing. Is anything wrong my
architecture?
Thanks for helping answers.
You can have another project that has only models for BLLEntities.
BLL will always have to map BLLEntities to DALEntities and DALEntities to BLLEnttiies.
You can use AutoMapper for that.
Any Layer above BLL should deal with BLL entities and not with DALEntities.
Related
I have .net core api project with following folders:
Models contains the database table classes and dbcontext
Services contain logic to send email, and business logic (example calculate student grade based on marks)
Controller contains the controllers with respective actions (api endpoints). The dbcontext is injected into the controller and the endpoints contain the LINQ queries (example: _ctx.Students.Where.....)
I want to organize this into layered architecture.
UI layer will contain the api project (controllers) and reference the business layer dll.
Business layer will contain the send email logic, and business logic (grading based on marks). I think this must reference the data layer to be able to fetch data.
Data layer will contain the table classes and db context.
Where do I place my entity framework queries which were previously in the controller action method?
I usually recommend people to use the repository pattern to structure Asp.net application in a monolithic fashion. At a high level, there are usually three-layer
Repository/Data Layer
Service/Business layer
Controller/API (Web Project)
In Repository Layer, we define all our models and database call(Your Entity framework will be here).
In the Service Layer, We perform all the business logic.
And in the web project, we define all the API endpoints and other client-side interaction services.
The followings are some of the articles related to the Repository pattern:
https://www.linkedin.com/pulse/repository-pattern-c-pawan-verma/
https://medium.com/net-core/repository-pattern-implementation-in-asp-net-core-21e01c6664d7
https://codewithmukesh.com/blog/repository-pattern-in-aspnet-core/
Some articles, here use the same project to define all the layers but you can simply separate all layers into a separate project (class library).
I usually layer my application like this:
APIs - EndPoints
Application Layer - All glueing code, mapping, orchestra code, utilities, and other application-level code comes here
Domain Layer - Purely contains domains, sub-domains, validations, interfaces for repositories and unit of work, and commands.
Data Layer - This layer contains the implementation of all the repositories and unit of work interfaces. And this is the layer where I keep all my queries and database-specific code.
I have an existing database which I am using in a CRM project developed in asp.net MVC project. Now our company has decided to develop HRM system also using the same database. The business requirement is to use Clean Architecture with .net core 3.1 as a backend for HRM. The project is structured in a way that it has four layers.
Presentation Layer: Contains Controllers and Web API endpoints.
Application Layer: Contains Application wise logic and types.
Business Layer: Contains Enterprise wise logic and types.
Infrastructure Layer: Contains all the cross-cutting concerns.
Presentation Layer and Infrastructure Layer are dependent on Application Layer and Application Layer is dependent on Business Layer. The business layer is independent of every other layer.
I have to scaffold the DB Context and Entities from the existing database so that Entities will go to the business layer and DB Context will go to the Infrastructure layer (Note: Infrastructure is not dependent on Business). How can I do that? Is there anyone who has done this earlier? Any help would be greatly appreciated.
I am creating an application that has those three different projects:
ApiService (Web API 2)
BusinessLogic (Class Library)
DataAccess (Class Library)
ApiService has a reference to BusinessLogic
BusinessLogic has a reference to DataAccess
DataAccess uses Entity Framework with code first approach so it contains the models for the database tables.
My question is, what is the best approach or best practice regarding the models for Business and Service Projects?
I have read that Service project should not be using the models of the DataAccess project, so where should I create that models, in Service or in Business?
Thanks in advance.
Separate BL(Business logic)/Presentation layer models from DAL(Data access layer) models always.
Add one more layer between them which will do the mapping, use Automapper or somethogn custom. So when you are passing data to DAL models will be mapped to entity models, and when BL is getting the data from DALsame thing, map entity models to BL models,
Why?
The way how you are persisting your data in your database may be rather different from how you are going to present it to the user. The data may have to be obtained from several entities, joined by relationships, constructed at run time again by joining from other tables, etc. How you are going to present it to a user may be simplified and different than it is persisted, so you can hide that complexity which is needed for the database.
I don't know if this is best practice, but I have made many projects that contain a lot of shared logic and functionality between windows services, Web APIs, etc. They have all followed something similar to this:
Wrapper - Contains interaces, models, and code to make calling the WebAPI from another .NET project easier. Has no references to the other projects at all
Core - Contains all the meaty business logic. Service layer, data access layer, helper classes, etc. References Wrapper and anything else needed to function
WebAPI - Contains only code necessary for creating a WebAPI around the service layer functions in Core References Wrapper for models/interfaces, and Core for business logic
Other projects that use Core would be similar to the WebAPI one. Examples would be a console app for scheduled tasks, Windows service for continual data processing, etc.
This results in what I've seen some people refer to as a "mega solution" or similar, but so long as you're keeping your code to one domain you're not creating a mess.
I am creating layered MVC Application that contains.
model layer: which is not using any reference for EF
Data Layer: which contains the infrastructure. (Repositories and unit of work ) and this layer referenced with Entity framework
Service layer
Web layer.
I am using Asp.net identity2. What I am doing is using ApplicationUser class in model layer and this leads me to reference model layer to Entity framework and Microsoft.AspNet.Identity.EntityFramework.
i am asking if there is a better way to do it, especially in feel that I am repeating my self while making both data layer and model layer using a reference to entity framework?
I don't think I completely understand your question but consider not mixing your identity model with your domain objects model:
ASP.NET Identity is a presentation layer logic and you have to consider if it's a good idea detaching it from your topmost layer (Web).
I would suggest you keep your Model or Domain project with Entity framework alone and avoid mixing it with objects that are directly related to presentation.
You can take a look at this post:
https://aarcoraci.wordpress.com/2017/02/15/asp-net-mvc5-entity-framework-repository-pattern-and-unit-of-work-revisited/
we have a classical 3-tier-architecture application. Now we face a little problem and we don't know the best way to handle it.
In the last layer (database-layer) we have a POCO-class, that gets filled with data from a database. In the top layer we have a MVC3 asp.net web-application. The MVC application would work best, if it could just read the POCO-class.
But as the GUI-layer cannot access the database-layer directly, it cannot get the exact same class.
What is the best way to get a POCO-class from the last layer to the top layer?
The actual issue is that your entities should not be defined in the data layer. Data layer, as well as any other layer in your app, might get completely rewritten one day, and you don't want entities themselves to be tied to any of these layers.
In other words, define your entities in a separate project, and then reference it from all other projects:
- Entities
- Data access layer
+ references Entities
- Business layer
+ references DAL
+ references Entities
- Presentation layer
+ references BL
+ references Entities
The same goes for repository interfaces: if you are using a repository pattern to abstract your data access, Entities project is the one which should contain all repository interfaces, which can then be implemented by a specific DAL choice.
You can create a project of DTOs that is referenced from all the different layer projects. This way you can share the DTO POCOs between all the layers of your application.