分层设计/架构 [英] Layered Design /Architecture
问题描述
我们在与DAL通信以进行数据访问操作的服务上使用带有Webapi的html 5 / angular SPA
we use html 5/angular SPA with Webapi at the service which communicates with DAL for dataaccess operations
层流为：
presentation（html5 / angular controllers / service）-> Web api-> DAL--> DB。
presentation(html5/angular controllers/service) --> web api --> DAL - -> DB.
我们没有BLL这样的项目。我们正在考虑将DAL作为BLL + DAL的组合。而且我们使用通过t4模板创建的DTO对象，它们用于在客户端与Web api和DAL之间进行数据传输（我们不使用EF，我们使用ADO.Net作为基础提供程序）
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)
- 我们是否需要一个单独的BLL项目，还是可以将BLL和DAL项目组合在一起？
- 如前所述，DTO对象始终被使用。我们是否需要DTO以外的其他模型在客户端和webapi / DAL之间传输数据？
DAL：
公共列表GetCustomers {}这使用数据访问帮助程序类来获取客户并转换为DTO
public List GetCustomers {} this uses Data access helper classes to get the customers and convert to DTO
CustomerDAL之上。GetCustomers正在由webapi项目调用。此时，（例如客户）的任何BL都写在Web Api项目中，有时也写在DAL项目中。我们正在考虑将它们移到一个项目中以实现一致性和可测试性。
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.
推荐答案
我从拥有单独的BLL中获得的最大价值是我的应用程序（业务逻辑）中最重要/最昂贵的部分位于与以下项无关的区域：数据库或Web / http框架。这意味着当下一个重要事物（数据库，平台等）出现时，我可以重用我的业务层。
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.
更重要的是，DAL和UI层的测试成本更高。当我在UI或DAL层上编写单元测试时，最终将每个功能测试1-2个场景...当我在BAL层上进行测试时，我将创建更多倍的场景，因为这么便宜（努力）。
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.
也许您的应用程序没有太多的业务逻辑。如果它们仅是围绕数据库表的CRUD包装器，则可能无法证明这样做的合理性。但是，大多数应用程序包含的业务逻辑远远超出开发人员想要的。查看您在WebAPI中运行的验证...这可能是所有业务规则。查看您的安全约束，这些约束也可能是业务规则。
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.
是否使用DTO或更复杂的域模型取决于您的设计，环境和团队约束，这不是十五年来我会轻松解决的问题分钟发布。 Fowler有很强的见解，称它为 Anemic域模型反模式，但我已经看到了成功地用于大型项目。该模型的优点之一是，您不需要应用程序模型的足够连贯的图片，大型分散的团队通常会遇到这种情况。
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.
这篇关于分层设计/架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
