asp.net web api - Layered Design /Architecture

Question

we use html 5/angular SPA with Webapi at the service which communicates with DAL for dataaccess operations

Layer flow would be:

presentation(html5/angular controllers/service) --> web api --> DAL - -> DB.

we do not have BLL project as such. we are thinking to make DAL as combination of BLL + DAL. And we use DTO objects created through t4 templates and they are used for transfer of data between client and web api and DAL (we dont use EF, we use ADO.Net as underlying provider)

1. should we require a seperate BLL project or is it ok to combine BLL and DAL proj? considering it should be testable and extendable.
2. as mentioned, DTO objects are used throughout. should we require any model other than DTO to transfer the data between the client and webapi/DAL?

DAL :

public List GetCustomers {} this uses Data access helper classes to get the customers and convert to DTO

above CustomerDAL.GetCustomers is being called by webapi project. At this point of time, any BL of (say. customer) is written in web Api project and sometimes at DAL project. we are thinking to move them to one project for consistency and testability.

any insights on this would be helpful.

Answer 1

The greatest value that I get out of having a separate BLL is that the most important / expensive bits of my application (the business logic), are in an area that has no dependencies on databases or web/http frameworks. It means that when the next big thing (database, platform, etc) comes along, I can reuse my business layer.

More importantly, DAL and UI layers are MUCH more expensive to test. When I'm writing unit tests at the UI or DAL layer, I'll end up testing 1-2 scenarios per function... When I'm testing at the BAL layer, I'll create many times more scenarios, because it's so cheap (effort-wise). This gives me much better coverage for much less cost.

Perhaps your applications don't have much business logic. If they are purely CRUD wrappers around database tables, it might not justify the expense. Most applications contain far more business logic than the developers want to admit though. Look through your validations that you run in your WebAPI... Those are likely all business rules. Look at your security constraints, those are likely business rules as well.

Whether or not to use DTOs or a more complex domain model depends on your design, environment, and team constraints, and is not something I would feel comfortably addressing in a fifteen minute posting. Fowler has some strong opinions, calling it an Anemic Domain Model antipattern, but I've seen it used quite successfully for large-scale projects. One of the nice aspects to this model is the fact that you don't need quite as much of a coherent picture of the application model, which is often the case with large, dispersed teams.