General N-Tier Architecture Question

In an N-Tier app you're supposed to have a business logic layer and a data access layer. Is it bad to simply have two assemblies: BusinessLogicLayer.dll and DataAccessLayer.dll to handle all this logic? How do you actually represent these layers. It seems silly, the way I've seen it, to have a BusinessLogic class library containing classes like: CustomerBusinessLogic.cs, OrderBusinessLogic.cs, etc. each calling their appropriately named cousin in the DataAccessLayer class library, i.e. CustomerDataAccess.cs, OrderDataAccess.cs.

I want to create a web app using MVP and it doesn't seem so cut and dry as this. There are lots of opinions about where the business logic is supposed to be put in MVP and I'm not sure I've found a really great answer yet.

I want this project to be easily testable, and I am trying to adhere to TDD methodologies as best I can. I intend to use MSTest and Rhino Mocks for testing.

I was thinking of something like the following for my architecture:

I'd use LINQ-To-SQL to talk to the database. WCF services to define data contract interfaces for the business logic layer. Then use MVP with ASP.NET Forms for the UI/BLL.

Now, this isn't the start of this project, most of the LINQ stuff开发者_运维知识库 is already done, so it's stuck. The WCF service would replace the existing DataAccessLayer assembly and the UI/BLL would replace the BusinessLogicLayer assembly etc.

This sort of makes sense in my head, but its getting really late. Anyone that's traveled down this path have any guidance? Good links? Warnings?

Thanks!

the way I've seen it, to have a BusinessLogic class library containing classes like: CustomerBusinessLogic.cs, OrderBusinessLogic.cs, etc

Ouch. Get and read Scott Ambler's "Building Object Applications That Work". Your approach does not and is a maintenance enightmare - no objects.

I'd use LINQ-To-SQL to talk to the database. WCF services to define data contract interfaces for the business logic layer. Then use MVP with ASP.NET Forms for the UI/BLL.

Yes. Great way to make the application artificially more complicated and slower than it has to be. Throw out the complete WCF service - what are they for? WCF is for SOA, and SOA lives in the user interface (i.e. it is a trust boudary and a user interface for another application to use). Unless you have that requirement.... it is stupid tointroduce additional slow technologies that just have overhead.

The WCF service would replace the existing DataAccessLayer assembly

The Daily WTF - what the heck do you have a DAL assembly for when you use LINQ to SQL? LINQ to SQL (the runtime) is your DAL.

Anyone that's traveled down this path have any guidance? Good links?

You basically picked every antipattern I can think of - maintenance nightmare, overdesigned with tons of useless technologies in there. You force layer technologies into a tiered architecture.

Read the book I mentioned.

About the XXXBusinessLogic, they become God Objects very quickly. Think in objects that make sense in your domain that represent the behavior, not in BusinessLogic "objects". These sort of "objects" will end performing ALL the work for XXX, and yes, they are a maintenance nightmare.