I've read the MVC5 with EF6 DB First tutorial. With this tutorial, it will generate code (controller and view).
I have created 3 projects in VS:
+ AdminWebSite
+ PublicWebSite
+ EntityFramework
And I've question, where should I implement the business logic, and share it will multiple website (Admin & Public)?
The business logic may include:
Logic with database (i.e. Transaction with multi-table)
Logic with SharePoint info
Logic with Email Server
EDIT
Typo, should be 3 projects instead of 3 solution, but it should be similar case, which AdminWebSite and PublicWebSite have add EntityFramework as reference.
EDIT 2
Before the MVC3, I will create a class project which includes all business logic, and also the Repository class. So that every WebSite or WebServices can use the same business logic (but I'm not sure is it the best practice).
But when move to MVC5 with EF6, the repository and unit of work seems gone. And don't want to implement repository for every table, which some tables just for direct CRUD without business logic.
I hope this can clarify the is Too broad.
Have a look in to this:
http://dombrovsky.github.io/EntityHooks/
It looks like a framework that is designed to work with EF6. It should allow you to write custom business logic when a certain event occurs like when a record is inserted, or updated.
You can utilize Projects under a solution.
I usually have the database layer in a separate project (Class library/DLL) and let other projects refer to it. This way you have only one copy of the ORM (Entity Framework) simplifying any changes in the database model. I also create a database project (if SQL server) that holds the actual schema definitions including tables and stored procedures. This is a great way to make changes in the schema and deploying it.
Anytime a significant enough portion of the code can be re-used it is usually a good idea to make it a class library and have client projects refer to it.
One solution include Web project 、BLL project 、 DAL project，web project contains publish and admin
I would not have a project named EntityFramework, I would suggest that you replace this project with a project named Infrastructure. This infrastructure project would contain classes that depends on external sources like EmailSenders and DAL classes like EntityFramework classes and other stuff that you for some reason in the future might want to replace with other external services.
Your business logic should be stored in a Core project. This core project would not reference either the web projects or the infrastructure project (but the web projects would reference both the infrastructure as well as the core project). If you need an EmailSender in the core project you reference an interface like IEmailSender, which is located in core as well.
This is basically the structure I would suggest:
AdminWebSite
PublicWebSite
Infrastructure
EF
Log
Messages
SharePoint
Core
Test (This project contains all your unit and integration tests)
I really suggest that you read up on using Dependency injection. When you understand DI, the separation of core and infrastructure will make sense and you see how these can use each other without any hard references.
If you dont want to use UoW or Repositories, I would suggest that you move EF to core but the infrastructure project is still very much valid for other external services.
Related
I know this question come back again and again, I read a lot about it, but I can't find an answer to my question.
I dont have a lot of exp on asp.net mvc but I already did a project using ef, repository and uow pattern.
In my last project, I had several layers including :
Web (project MVC)
BLL (my business layer)
DAL (data acces, with ef context, repository and uow implementation)
Now, I want to start a new project, with EF6. I read that uow is not need and I want to give a try.
So far I understand that you must pass your dbContext to your services and your services to your controllers, am I right ?
So you must have a ref to entityFramework in your service layer too ? Still right ?
And because of identity implementation, you need a ref to entityFramework in your UI too.
So what's the point of layer anymore ?
If I read this microsoft guide, all I have to do its make a folder to my DAL and other layer ?! Dont seem right to me ... But maybe ?
I read this post too, who seem to confirm my opinion. And if you add unity and configure it in your UI, its just more ref in your UI :)
So my question is, if you must start a new project now, with EF6, asp.net MVC5, what will you do ?
Am I right to want to do layer ? Or just go on with my MVC project only ?
The ONE thing I miss, is a tuto who explain step to step how to start with microsoft MVC 5 template and transform it with layer, decoupling identity, and finally no ef ref in my UI. Is this thing exist ?
There is no silver bullet here. Some people do it one way, some - the other. Depending on level of abstraction needed. I used to have 3 projects:
Web
Core/Business (Services)
Model/EF/Domain (Entity Framework context and models)
And it's fine if Web has reference to Domain or EntityFramework. Web can return EF Models (just to avoid code duplications). And if you need more complex model, you create ViewModel.
I don't recommend using UoW or Repository pattern (unless you really need it). EF context is already an implementation of UoW pattern. If you want to implement repository pattern with Entity Framework, don't expose anything related to EF in the interface e.g. SaveChanges(), Dispose() as in this case you will not take advantage of repository pattern benefits.
So this is how I would build typical small/medium ASP.NET MVC + EF website. But like I said, everything depends on level of abstraction needed. Abstraction level is proportional to amount of code needed to write. So think first and keep it simple. Good luck.
I like the repository pattern very much, since it abstracts your actual data store from your client application. The front end doesn't need to know where the data comes from, it can be either from frameworks such as Entity Framework but it could as well be a simple converted DataTable. This is a generic approach and you can reuse it for all your future projects if your repository framework has passed all your tests. This tutorial gives you a good view on how to implement the combination of UOW and Repository pattern.
Basically your client application (=MVC) doesn't need to have a reference to Entity Framework, it is sufficient for your service layer to have a reference. You then use this reference to pass your own DbContext to the repository layer (assuming that you have written a repository layer for Entity Framework), ideally through DI containers like Unity.
Of course, there is a lot of discussion about whether or not to use the repository pattern with EF (as it already is an abstraction of your database) but I think it's a good exercice of creating and using reusable components.
Premise:
I am exercising Domain-Driven Design and I separate my solution into 4 layers:
Presentation Layer
An ASP.NET Web API 2 project for a RESTful API web service
An ASP.NET Web MVC5 project for a documentation and admin screens
Application Layer
A class library project responsible to take commands from presentation layer and consume any domain services
Domain Layer
A class library project that contains business models and logic
A class library project that contains the domain services
Infrastructure Layer
A class library project that contains all the concrete implementation, like dataq persistance using Entity Framework, logging using Log4net, IoC using Simple Injector, etc
The domain layer only has a set of repository interfaces defined for the aggregates and it's up to the implementation data access mechanism which exists in the infrastructure layer to hide the implementation details.
In this exercise, I decide to use Entity Framework Database first approach. And of course, there is a app.config in the infrastructure project that contains a connection string.
Problems:
Ok, I spend a great deal and time trying to separate all the concerns and to focus on domain models. In the presentation layer (i.e., the API and MVC projects), there is no direct reference to the infrastructure project. And IoC container has been setup so all concrete implementation of the required interfaces would be injected into controller constructors.
When I select, for example, the API project as start project and run it, I got
An exception of type 'System.InvalidOperationException' occurred in EntityFramework.dll but was not handled in user code.
Additional information: No connection string named 'xxxxxx' could be found in the application config file.
Question:
Now I understand if I install Entity Framework into the API project, copy and paste connection string from the app.config of the infrastructure project into the web.config of the API project, things will work. But that breaks our original purpose of separating concerns, doesn't it? If we do that, then what's the point of using Domain-Driven Design and making the data access technology ignorance from the presentation layer?
The reason we don't directly reference direct implementation of data access technology (i.e. concrete implementations that use dbContext and Linq) is that we could easily switch the underground access technology to something else.
So what would be the proper way to do it?!!
I do not want to install Entity Framework in my presentation layer, nor copy the connection string everywhere. I want all the data access and concrete implementation of repositories exist in just one library.
The Entity Framework configuration must be in the project where it is being used. This doesn't mean it's going to break your layered structure or your separation of concerns.
Remove all entityframework elements from your app.config. Create your own connection string element and provide it to entityframework on app startup.
Since I am new to MVC I have a few questions about the database connection.
I am trying to build an MVC application, and so far I have built 2 layers: Model(where my classes are, without any functionality) and Business (there is the functionality for my classes, every class has its own Business class) and there is also my MVC application. Both these layers are separated from the MVC project, I use them as ".dll-s". I am also using the repository pattern and the dependency injection is done by Unity.
Now comes the tricky part (or at least it is for me). I want to bind my application to a database. Most of the tutorials I have found rely on Entity Framework, but I don't want to use it, I want to use ADO.NET (Entity Framework makes me feel like I am giving my "power" away, so I want to manage the SQL on my own). So what is the best way to do it? How can I access the Web.Config from outside and read the connection string (or should I take care of the connection string inside the data access layer)? Is there any best practice how to manage the connection from "outside"? I mean I could easily just create a dbaccess object inside my MVC application, but I don't want that. In the MVC application I just want to use my business(object) classes.
And one more thing. What is the best practice for DataAccess: to build a new layer, or is it also fine to include the functionality inside my business layer? I am more tending to build a third layer, so I can reuse this code for any other application but maybe there are some other approaches.
You can create another project called "DAL" to handle your data access layer which is built using pure ADO.NET. You will add a reference to the entity project so that you can return these entities from your Data access methods. Now from your Business Layer, Add reference to the Data Access projects so that you can access these data access methods from the Business layer classes. From your MVC project, Add reference to your Business project ( and entities project if you are using those entity objects in your MVC project). In this way your MVC project do not have any idea what data access technology you are using.
You do not need to have connection string in your DAL project, Keep that in your UI MVC project and your DAL project will be able to read it as long as you have the proper references added between these projects.
I have a Solution with one project is Entity Framework and have my ASP MVC project, I looking for some advice or opinion about the idea of create in top of my POCO objects and the DBContext, a Business Logic Layer with static classes that have the all the methods (example a ContactBLL class with GetContactByID, GetAllContacts, GetContactsByType) to allow the access to the model data and that can be accessed in the Controllers Actions. In that way I don't have to put the implementation code of this methods in Controller Actions methods, and it can be reusable invoking this methods in other Action Controllers. I will appreciate your opinion because it could guide me to respond a question I've asking to myself around a week based in the answer to this one (about where to define the DBContext and how use it).
You can create different projects according to core functionality.
Data Access Layer(DB context and repository etc.) you can make Project.DataAccess, it will have only db context class and repository.
Business Logic Layer(Project.Business) it will have business logic and make call to data access layer.
UI Layer(Project.WebUi) it is mvc project.
and so on.
for detail info you can see this http://prodinner.codeplex.com/ code
Create separate class library for your POCO,
then create another class library for your repository, this should
include only the interfaces needed for your repository
and the implementation will be on another class lib like Project.EF,
Project.NH which will include Entity Mapping, Migration, Repository
implementations. but in reality, chances are you wont be changing
your ORM lib once it was implemented because it will just cause you
a lot of headache(just my 2cents).
you'll create your business layer(class lib) and
web project as separate lib. Models folder of your MVC project will contain your ViewModels.
this is what Im using right now and of course not the best structure, it just something that Im happy with :). hope it helps.
In general, there are four standard projects in a ASP.NET MVC - Entity Framework solution. They are 1) MVC, 2) Core/Business Logic Layer(BLL), 3) Data Access Layer/DBContext (DAL) and 4) Common/Utility.
Standard MVC project consists three main elements which are Model, View and Controller. However, middle to complex solution usually cuts off the Model element from MVC project and moves it back to BLL, we call it as ViewModel(POCO). Following this structure, MVC project is now responsible for employ/use the services from BLL and control the UI through controller.
Business Logic Layer (BLL) is the core of implementing business logic. It is responsible for serving request from the MVC project and work with DAL to persist data. As said above, BLL is the place to define ViewModel, its relations as well interface/ abstract class to support implementing design pattern. Viewmodel(POCO) is likely mapping one-one to data entity at DAL but we do not use the data entity directly on View. Following this structure will help to increase the customization on ViewModel like adding constrains
DAL is the place for DBContext and its data entities.
Common project consist of shared functions like Logging which is used in 1) 2) and 3)
Please read more at
https://www.codeproject.com/Articles/70061/Architecture-Guide-ASP-NET-MVC-Framework-N-tier-En
https://chsakell.com/2015/02/15/asp-net-mvc-solution-architecture-best-practices/
I have the following task:
I have to create the following: Domain Logic, Data Access Layer, Database.
I will also have to create an ASP.Net Page to work with the aforementioned pieces (ASP.Net is only part of the system, there may be a desktop app etc).
I want to use the Entity Framework as the Data Access Layer, but here is my confusion:
I dont know how I should go about creating the different layers... I cant work out what project type they would be..I would usually use the ADO.Net Entity Framework within a C# Windows Form project with a SQL Database. However, the fact that I will have ASP.Net and Windows Forms possibly using the domain logic confuses me as to how and where I would place each part? The Domain logic, the DAL and the Database..? Also, how would I interact with each layer? Any help would be GREATLY appreciated as I have no clue how to go about this currently.. I hope I explained this reasonably, Thank you.
I would create separate projects for each, i.e:
Library project that houses the models
Another library project for business/domain logics
Web project (ASP.NET / MVC)
With that setup, you can reuse your library projects in WinForm, WPF, etc... project by just referencing the libraries.