我们用html 5 /角SPA用的WebAPI在其与DAL连通用于数据访问操作的服务
层流将是：
演示（HTML5 /角控制器/服务） - >网页API - > DAL - - > DB。
我们没有BLL项目本身。 我们正在考虑使DAL为BLL + DAL的组合。 我们通过使用T4模板创建DTO的对象，它们被用于客户端和Web API和DAL（我们不使用EF，我们使用ADO.Net为基础提供）之间的数据传输
- 我们应该需要一个单独的项目BLL还是确定以BLL和DAL凸出结合？ 考虑到它应该是可测试的，可扩展的。
- 如所提到的，DTO对象通篇使用。 我们应该要求比其他DTO任何模型到客户端和的WebAPI / DAL之间传输数据？
FROM：
公开名单GetCustomers的{}这个使用数据访问助手类来获得客户，并转换为DTO
上述CustomerDAL.GetCustomers是由项目的WebAPI叫。 在这一点上的时间（比方说，客户）是写在网络API项目的任何BL，有时在DAL项目。 我们正在考虑将其移动到一个项目的一致性和可测试性。
在这个任何见解将是有益的。
我得到了有一个单独的BLL的最大价值在于，我的应用程序（业务逻辑）的最重要的/昂贵位，是在对数据库或Web / HTTP框架没有依赖性的区域。 这意味着，当未来的大事情（数据库，平台等）出现时，我可以重复使用我的业务层。
更重要的是，DAL和UI层要贵得多测试。 当我在UI或DAL层编写单元测试，我将最终每个功能测试1-2情景......当我在BAL层测试，我会创造出很多倍的情况下，因为它是这么便宜的（努力明智）。 这给了我更好的覆盖面更低的成本。
也许你的应用程序没有太多的业务逻辑。 如果他们周围的数据库表纯粹的CRUD包装，它可能收不回成本。 大多数应用程序包含远远业务逻辑比开发人员希望，虽然承认。 翻检验证您在运行的WebAPI ......那些很可能所有的业务规则。 看看你的安全约束，这些都是有可能的业务规则也是如此。
无论是否使用DTO的或更复杂的域模型依赖于设计，环境，和团队的约束，而不是我会觉得舒服在十五分钟的发布寻址。 福勒有一些强烈的意见，称这是贫血的域模型反模式 ，但我已经看到了它使用非常成功地用于大型项目。 其中一个很好的方面，这种模式是，你并不需要相当多的应用模式，这是经常用较大，分散的团队的情况下的一个连贯的事实。
