We Keep Coding

Asp.Net MVC project with n-tier architecture

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.

Using the repository pattern, how do I reference my domain models without creating a leaky abstraction?

Setup
.NET, C#, WebAPI, Entity Framework using code-first migration
Summary
I am designing a .NET solution using the repository pattern. The repository sits at the bottom of my stack and currently contains my domain models. I have layers on top of the repository (e.g. BLL) and finally I have an API layer on the top of the stack which contains my RESTful API endpoints.
Here is a simplified pseudo-diagram of the current solution stack:
-API
-BLL
-REPOSITORY
Problem
In the API layer, I would like to use .NET's ModelState validation inside each of the controller's endpoints. Problem is, this requires that the API layer have a reference to (ergo knowledge of) the Repository layer. Wouldn't this be a leaky abstraction?
It seems like the use of Data Transfer Objects would be the solution, but this almost seems silly since they would be essentially identical to the Domain Models in the Repository. That doesn't allow for much abstraction.
An alternative?
I am kicking around the idea of adding a separate project to contain the Domain Models, and then allow the API, BLL, and Repository to all reference that project. Any reason this shouldn't be done?
The only downside I see here is that now three of the projects in my solution will need access to the database:
API (because I have set up OWIN authentication in the API)
Repository
DomainModels (because I am using code-first migration)
Any help is appreciated.

The repository sits at the bottom of my stack and currently contains my domain models
That's your problem, the repository uses domain entities, but it doesn't contain them. The repo is part of the persistence, your domain model should be part of the Domain layer. The repo interface is part of the Domain too.
ALso, you domain model should be different (as a concept) than you persistence model i.e the pocos you're using with EF to do CRUD stuff. The domain objects are modelled according to the business view, the persistence pocos are designed with db usage (store/easily queryable) in mind.
The domain layer should be at the core, persistence and application services should use it i.e depend on it. You can take a look at the onion architecture or business components/ vertical slices (which is a more advanced approach IMO)

Do I need to add reference to EntityFramework.SqlServer in presentation Layer?

I'm writing an MVC web application using 3 tiers, Web, BLL and DAL. I've chosen MVC 5 Code first approach for my needs. My context and model classes reside in DAL. I'm implementing the repository pattern in my BLL that gets data from DAL, loads the data into ViewModels and serves the requests from the Web layer.
WEB --> has reference to BLL
BLL --> Has reference to DAL (entity framework installed on BLL)
DAL --> (entity framework installed on DAL).
I have entity framework installed on both DAL and BLL because I use DBSet or IDBSet in those both layers.
Now, the problem is, when I run the application, i keep getting the below error. It doesn't go away unless I install the entity framework on the Web layer, which i'm hesitant to do. I do not like to add entity framework to the web layer unless i absolutely have to. But the dll that's killing it is EntityFramework.SqlServer.
ERROR:
No Entity Framework provider found for the ADO.NET provider with invariant name 'System.Data.SqlClient'. Make sure the provider is registered in the 'entityFramework' section of the application config file. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.
Please let me know if I can do this without having to install entity framework on my web layer. Any input is greatly appreciated.

The way that I understand it, is that when you use MVC, each layer will be independent of the other (meaning that certain dependencies, such as catering for a particular DB engine, should not bubble up to the view layer, as per your dilemma).
If I am understanding your question correctly, you are saying that you have Database related data sets in your Middle Tier as well. I think that this is not the way to go since you are constraining your middle tier to use database related data structures.
The way I see it, should not be a problem for the DAL to internally use database oriented data structures internally, however, it should interact with the other segments of your system through the use of traditional data structures such as Lists and Sets.
The same applies for the middle tier. If you do this, you should be able to keep entity framework reference requirements contained within your data layer. An everything would be self contained (reference wise).

You should have all references in composition root. In your application composition root is web layer so you should add this reference to project. But you should not use its classes in web layer.

n-tier and objects that are needed in every tier?

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.

Entity Framework and 3 layer architecture

I have a three layer architecture program. The questions are:
1. Data access is the layer of EF?
2. If i want to use an entity generated by EF from Presentation Layer, then i reference the Data Access, but this violates the principles of 3 layered architecture.

Microsoft Spain released a pretty good documentation, guide and sample application for N-layered applications on codeplex, you can look it up here:
http://microsoftnlayerapp.codeplex.com/
You will find many directions and helpful implementation patterns there.
hth.

Yes EF would be your Data Access Layer.
With EF you can use T4 templates with POCO support, you can then extract these POCO into a seperate dll and this will be reference from all of your layers.

What type of application are you building? If you are building an ASP.NET MVC 3 application, you can have your View be the presentation layer, your Model is your data access (which can use EF) and the controller and / or Action Filters can contain your business logic and in this scenario you will be using your EF Model in the presentation layer but still satisfy the separation of concerns principle.

EF does two things: -
1) Generates an domain model for you (optional, but commonly used)
2) Gives you the ability to query / modify your database via that domain model.
This can give the appearance of blurring the lines between domain model and data access but the two are indeed separate.
As long as you're not doing stuff like creating object contexts and writing queries directly in your presentation tierthen IMHO you are not breaking abstraction - the only thing you are "breakin"g is the fact that you will need to reference System.Data.Objects (or whatever the EF dll is) in your presentation project(s) (which is just a physical artifact) unless you go down the route suggested by Jethro to generate your domain model into a separate project.

For the three tier architecture. I would consider doing Abstraction using Domain Model and Data model pattern rather then doing direct EF from Presentation Layer.
So the idea is that you have your Data Model which has EF POCO classes with Repositories which knows how to access these Classes for various CRUDs.
Your Domain Model would have models related to your Client (so you can put various ViewModels or Validation related code), It can be a WPF or MVC web app.
Now between these two there is a business which talks to both Domain and Data models.
Your Presentation Layer does know nothing about the EF/Data Layer/Repository. When you want to introduce new Data Framework or database, you just need to write new repository classes and data models classes (which prob. be with some sort of code gen).
This also allows your code to be Unit testable as well.