In the N-Tier app, you must have a level of business logic and a level of data access. Is it bad to just have two assemblies: BusinessLogicLayer.dll and DataAccessLayer.dll to handle all this logic? How do you actually represent these layers. It seems silly, as I saw it, to have a BusinessLogic class library containing classes such as CustomerBusinessLogic.cs, OrderBusinessLogic.cs, etc., Each of which calls their cousin with the corresponding name in the DataAccessLayer class library, i.e. CustomerDataAccess. cs, OrderDataAccess.cs.
I want to create a web application using MVP, and it does not seem as sharp and dry as this. There are many opinions on where business logic should be placed in MVP, and I'm not sure I found a really great answer.
I want this project to be easily verified, and I try to stick to TDD methodologies as much as possible. I intend to use MSTest and Rhino Mocks for testing.
I was thinking of something like my architecture:
I would use LINQ-To-SQL to talk to the database. WCF for defining data interfaces for the business logic layer. Then use MVP with ASP.NET forms for UI / BLL.
Now, this is not the beginning of this project, most LINQ material has already been completed, so it’s stuck. The WCF service will replace the existing DataAccessLayer assembly, and the UI / BLL will replace the BusinessLogicLayer assembly, etc.
This type makes sense in my head, but it becomes very late. Anyone who has traveled this way has any guidance? Good links? Warnings?
Thank!