分层设计/建筑 [英] 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 controller/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 之间传输数据?
达尔:
public List 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 或更复杂的域模型取决于您的设计、环境和团队限制，我不会在 15 分钟的帖子中轻松解决这些问题.Fowler 有一些强烈的意见，称其为 贫血域模型反模式，但我已经看到了非常成功地用于大型项目.此模型的优点之一是，您不需要非常清晰地了解应用程序模型，而大型分散的团队通常就是这种情况.
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屋！
