Three tier app in C# - where to put data and business models

Question

I am building a standard three tier application in C#

1 Console app for front end/but I might change this to a ASP.NET MVC web page

2 Business logic layer

3 Data layer using Entity Framework connected to an SQL database/but this might change to windows azure

The main purpose is to display some customer data.

The customer stored in the database has the following fields -

CustomerID
Firstname
Lastname
DateOfBirth
Othervalue1
Othervalue2
Othervalue3
Creationdate
Updatedate
IsDisabled //this represents "deleted" customers i.e. the app will never use deleted customers, but I want to keep them in the database anyway 

In the middle tier, I only want

CustomerID
Firstname
Lastname
DateOfBirth
Othervalue1
Othervalue2
Othervalue3
Updatedate

And in the front end for the first application I'll only show

CustomerID
Firstname
Lastname
DateOfBirth

How do I properly implement an n-tier app from the perspective of loading a Customer from a datalayer (that might change) and using that Customer in the middle tier and then in the presentation tier (that might change)?

Where do I put the Customer model? Do I need more than one? Do I need an ICustomer interface somewhere?

Project details The project will be developed by two teams, one located in the US, the other in Eastern Europe, there will be between four and five team members.

There is a legacy data access layer which this project will NOT be using. Instead, we will build a new one with Entity Framework; we need to design and build a data layer that will be used in all new applications (for this app we only need the customer table and one or two tables). Other projects will add other tables to this layer.

I am using DI to inject the ICustomerRepository (see this SO question). But will implement the repository and unit of work patterns.

My concern is about separating the layers appropriately. We will be adding many new projects over the next few months and the new data layer will grow quickly. We are also considering a move to Azure at some point, so I want to be able swap out the Entity Framework data layer without having to rewrite the business and frontend layers.

Answer 1

You have a data model (the DB schema), a domain model, and a view model.

If your goal is to decouple the layers, you should have distinct classes representing Customer in each of those three layers (but see the article @Joe mentions in the comments).

Your data access technology will drive the mapping of data model to the domain model. If you use Entity Framework, it provides the capability to map between those two models.

For mapping of the domain model to the view model, have a look at Automapper for mapping between domain objects (e.g. business objects) and view models.

UPDATE

Based on your new information, I'll share what I would do. It's certainly not the only valid approach.

Given a distributed team, clear lines of responsibility are important. Different people, in different time zones, with different team leads, will be working on the code.

Given new software being built upon a legacy database, you must be aware of three facts:

• It will not be easy to change the legacy database to accommodate the needs of the new software.
• The new software should not inherent a sub-optimal design because of the structure of the existing database.
• Data that would pollute the design of your current application might be needed in the next application you build.

I would do the following

• Create Data Transfer Objects (DTOs) that represent the structure of the legacy database.
• Use the Repository and Unit of Work Patterns to provide access to the DTO's for the business object layer.
• Design the business object layer (middle tier, whose classes are often called Entities) according to the needs of that application. Don't pollute the object design based on the structure of the DTO's (ultimately the structure of the legacy DB).
• Use a technology such as Automapper to ease the plumbing work of mapping between those two layers.
• Create UI objects (called Models in MVC terminology) that represent data that a given UI screen (View in MVC terminology) will process.
• Depending on how closely the UI Models align with the business objects (Entities), you might want to use Automapper, or might just want to populate them in custom code.

Again, that's how I would approach it given my background, experience and preferences. It's not the only valid approach.