如何在不设计航天器的情况下在我的架构中正确地分离关注点？

Question

在my last question中，我发布了一些关于我如何尝试实现关注点分离的示例代码。我收到了一些不错的建议，但我仍然不“明白”，也不知道如何在不设计下一个航天飞机的情况下设计我的应用程序来正确地分离问题。

我正在工作的网站(从旧的ASP逐段慢慢转换)是中等大小的几个不同的部分，包括一个商店(每天约100个订单)，并获得相当数量的流量(约300K个/月)。我是主要的开发人员，可能有最多2-3开发人员，也将在系统上工作。

考虑到这一点，我不确定我是否需要完整的企业级架构(如果我错了，请纠正我)，但由于我将在接下来的几年里致力于这段代码，我希望它表现良好，并根据需要易于扩展。我正在学习C#，并试图从一开始就整合最佳实践。以前的ASP站点一团糟，这一次我想避免这种情况。

我目前在这方面的尝试最终是一堆DTO，这些DTO具有验证并调用DAL层以进行持久化的服务。这不是故意的，但我认为它现在的设置方式是一个完美的贫血域模型。我一直试图通过将我的BLL转换为域对象来解决这个问题，并且只使用DTO在DAL和BO之间传输数据，但这是不起作用的。我也有我的所有DTO/BLL根据数据库表/功能划分(例如- YouTube风格的应用程序-我有单独的DTO/BLL/DAL的片段，视频，文件，评论等)。

根据我所读到的，我至少需要使用存储库，可能还需要使用接口。这很棒，但我不确定如何继续前进。请帮帮我！

Answer 1

在我看来，您有四点需要解决：

(1)“考虑到这一点，我不确定我是否需要完整的企业级架构”

让我们先来处理一下高层次的乱码。这取决于您所说的“完整的企业级架构”是什么意思，但简短的答案是“是”，您需要处理系统的许多方面(这将取决于系统的上下文，即主要方面是什么)。如果没有其他内容，关键字应该是Change和Supportability.您需要以一种支持未来更改的方式来构建应用程序(逻辑和物理分离的关注点(依赖注入对于后者来说是一个很好的选择)；模块化设计，等等)。

(2)“如何在不设计航天器的情况下在我的架构中恰当地分离关注点？”

我喜欢this approach (这是我写的一篇文章，它提炼了我在那之前学到的一切)--但这里有个要点：

​

看看这个，你将至少有六个程序集--这并不是很大。如果你能将你的系统分解成这些大的存储桶(独立的关注点)，那么它应该会在很长一段时间内满足你的需求。

(3)详细信息

将关注点分离到不同的层和类是很棒的，但如果您希望能够有效地处理更改，则需要更进一步。Dependency Inversion (DI)是这里要使用的一个关键工具。当我学习依赖注入时，它是一个手工的东西(如上一个链接所示)，但现在有很多框架(等等)。如果您是DI的新手(并且在.Net中工作)，本文将引导您逐步了解基础知识。

(4)如何向前发展

使用DI等方法获得一个简单的垂直切片(从UI一直到DB)。在这样做的同时，您还将构建系统将使用的框架的骨架(子系统和主要管道)。

在第二个切片上开始工作；在这一点上，你应该发现任何你无意中没有重用你应该做的事情的地方-这是在你构建切片3、4和5之前改变它们的时候-在有太多的返工之前。

评论的更新：

你认为我应该完全放弃web表单，从头开始学习

，还是只利用我现在所知道的？

我不知道，但要让答案是“是”，你需要能够用“是”来回答以下问题：

• 我们有使用和支持MVC所需的技能和经验。
• 我们有时间进行更改(进行此更改有明显的好处)。
• 我们知道MVC更适合我们的needs.
• Making。此更改不会危及成功的交付。

...do我需要移动到项目并将这些层中的每个层设置为单独的项目？

是。项目与程序集一一对应，因此获得松散耦合的好处您肯定希望以这种方式分离事物，并注意设置引用的方式。

当您提到POCO时，您是指DTO还是富领域对象？

DTO not Rich Domain Object。但是，如果你来自Martin Fowler学派，人们似乎可以互换使用POCO和DTO这两个术语，而严格地说，它们并不是。在他看来，DTO应该是一堆POCO(或其他对象(？))打包在一起，以便“通过线路”发送，以便您只对某个外部系统进行一次调用，而不是多次调用。

每个人都说我不应该将我的数据结构暴露给我的UI，但我说为什么不呢？

管理依赖项。您不希望您的UI引用physical数据结构，因为一旦该数据结构发生更改(而且它将会更改)，您就会(使用技术术语)搞砸。这就是分层的全部意义。您想要做的是拥有UI depend on abstractions，而不是实现。在5层架构中，POCO可以安全地使用，因为它们是“某些东西”(一个业务概念)的抽象/逻辑定义，因此它们应该只在存在业务原因时才会更改-所以在这种意义上，它们是fairly stable and safer to depend on。

Answer 2

如果你正在重写你的eCommerce站点，你至少应该考虑用一个标准的包替换它。

现在有更多这样的包可用。因此，尽管构建原始网站的决定可能是正确的，但构建自定义应用程序可能不再是正确的决定。

这里列出了几个eConmmerce平台：Good e-commerce platform for Java or .NET

它的成本应该比2-3个开发人员的工资低得多。