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.
Related
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.
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.
I have a strange situation. I have created a data model visually and generated a database from it. This project is referenced by two projects:
ASP .NET application.
WinForms application.
The ASP .NET application deals directly with the database while I need the WinForms application to interact with the database via the Web application.
I have created a page called API.aspx and use HTTP POST to send values and get results in XML.
However, since the WinForms application still needs to use the data model classes, I am running into issues using them without creating a database object.
What is a good strategy to use in this scenario?
If you have implemented your code with loose coupling (See the Repository Pattern), then you could create a database stub that will return dummy data (or in memory data) until you are ready to plug in the actual EF framework.
This is generally good practice to create a clean separation of concerns.
This sounds like a candidate for an SOA implementation, rather than having the windows forms app communicate directly with the web application:
http://en.wikipedia.org/wiki/Service-oriented_architecture
http://msdn.microsoft.com/en-us/library/aa480021.aspx
I Am creating a web application and first use Entity Framework. I created Entity Data Model and now I am not sure, how to proceed now.
Premise: My database is really simple (Rating, WebPage, Visitor) and database tables corresponds to the business objects.
My suggestion is 3tier architecture but how to make it?
It is good idea create partial classes with the same name as Entity Framework objects (Rating, Visitor) and declare here new methods (GetAverageRating()...)? Or is better create some VisitorProvider, RatingProvider and place logic here?
It is better use EF objects in BLL and Presentation Layer or I should create my own BO objects on my BLL layer and transform EF object to BO?
I'm think, it is more practical use static methods on my DAL than instantiate classes on BLL. Do you agree?
Can you recommend me some best practices? I have many ideas how to create it, but I do not know what is the right.
3 layer architecture is quite popular but what it really means?
Presentation layer
Application layer
Database layer
If you ask what each layer means you can be pretty sure you will get several different answers. You can further divide each layer into sublayer and build layered hell like:
Client side presentation layer
Server side view layer
Controller layer
Service facade layer
Service layer
Domain objects layer
Repository + Factory layer
ORM layer
Stored procedure layer
Database view layer
Database table layer
WTF? That is just example that application can be easily over architected. It can go even worse if you insist that only neighbours can exchange data and if you decide to add special type of objects to be exchanged between layers instead of flowing sing set of objects through multiple layers.
Add layers which you need to make you more comfortable with developing the application and which will do reasonable separation of concerns and maintainability needed for the scale of your application. You can simply do the most simplest application which will be used just few weeks and must be developed as fast as possible. In such case you can do that within few days simply by using ASP.NET web forms and data source controls (or ASP.NET dynamic data). It can be badly extensible but in such situation it is exactly what you need to implement application quickly. Writing layers and doing all the stuff around maintainability and extensibility is reasonable if you need it. Another quick prototyping technique is ASP.NET MVC Scaffolding which can create quick multilayered skeleton of the application which can be further modified.
Both approaches are correct and it only depends on the approach you like. The first is called active record pattern but it is not used very often with entity framework. The second approach is more popular. You can either use EF directly in some middle class which you called Provider (common name is also Service). This class will do both data access logic and business logic. In more complex applications developers like to somehow wrap EF to separate class following repository pattern and call the repository either from service or directly from web app. code behind or controller (depending on amount of business logic). Try to do it without repository first. My personal opinion is that people should start to use repository only once they understand EF itself.
Again both approaches are correct. In a simple application it is fully acceptable to create EF model with POCO classes (EFv4.x) and use them in all layers. If you are using ASP.NET MVC you can find that you need special classes as view models to fully represent needs of your individual views. In a more complex application you can have separate objects exposed from a business layer - this is especially used if the business layer is exposed as a remote service (WCF).
It depends how you write these DAL methods - it is absolutely necessary to not share the EF context among requests! It also depends if you want to write some test or not. Layer defined by static methods is something which goes directly against testable architecture where you want unit test just single layer (unit testing with EF can be hard). It also depends if you want to use dependency injection which is based on instances.
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.