CODEWITHSUNDEEP
c#3-tier
Roesmi
Roesmi

Reputation: 508

3-Tier - Models reusing?

I am creating an application that has those three different projects:

ApiService (Web API 2)
BusinessLogic (Class Library)
DataAccess (Class Library)

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.

Upvotes: 2

Views: 85

Answers (2)

Milenko Jevremovic
Milenko Jevremovic

Reputation: 1056

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.

Upvotes: 2

Logarr
Logarr

Reputation: 2417

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.

Upvotes: 0

Related Questions