N层架构的实际应用

Question

N层架构的实际应用

n-tier-architecture

4

我是一名.NET Web开发人员，为一家小型组织工作。我们这里有一些熟练的开发人员，但我们缺乏在更大、更有组织的软件公司工作过的人员。我们做得不错，但我发现自己想要更好地组织我的代码，却没有什么地方可以求助。

问题就在于，我们组织中的某个人决定，无论什么情况下，我们都要使用Web服务来进行数据访问。因此，我们的硬件架构被组织成只能通过这种方式访问数据库。理论上听起来很好，但问题是我们的大多数应用程序最终都像这样：

aspx.cs中的混乱代码 -> 仅调用存储过程的Web服务

除此之外没有太多的分离。每当我开始尝试研究更好的结构实践时，我就会开始阅读关于依赖注入、脏属性和类工厂等内容，我的头开始晕眩，然后我沮丧地转向其他事情。

这里是我的疑惑的一个基本示例。所以，假设我必须制作一个页面来选择员工列表，编辑它们并更新数据库。是更好的方法在获取时让Web服务返回一个Employee对象，并在更新时接受一个Employee对象呢？还是更好的方法是让Employee对象调用Web服务自我填充？

换句话说：Employee emp = svc.GetEmployee(42); vs Employee emp = new Employee(42);

第二个示例似乎对于更新（更新相关属性并调用emp.Update()）来说更好组织，但问题是如果我需要获取员工列表怎么办？对于单个员工使用Employee emp = new Employee(id)是不一致的，但对于列表使用svc.GetAllEmployees()。

我觉得我有点啰嗦了，所以我要停止尝试解释，并希望有人能理解我的困惑。我感激任何人可以提供的建议。谢谢！

- Landon

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- David · Accepted Answer

与任何其他事物一样，您可以采取许多不同的方法。（因此希望会有很多不同的好答案，因为这绝对是一个重要的问题。）

你应该考虑的一个问题是“应用程序之间需要共享多少逻辑？” 根据您提供的小GetEmployee示例，似乎您想知道在领域中应该放置模型。这些模型是否由多个应用程序使用？业务逻辑是否在应用程序之间共享？

如果是这样的话，您可能希望将领域模型放在Web服务后面。也许在这些服务的后面建立一个丰富的领域，其中包括其数据访问和外部依赖关系（请记住这个依赖注入的东西，最好的设计决策必须位于服务层后面的领域中，因为那是整个系统的核心）。

然后，当然，如何访问此逻辑呢？再次，有很多选择。我个人最喜欢的设计是具有抽象化服务层的请求/响应系统。像NServiceBus这样的东西非常酷，适用于真正脱机的异步系统，像Agatha这样的东西则很简单，只需将实际服务抽象化并在代码中放置请求/响应逻辑，或者尝试使用ServiceStack（我一直想做的事情）或另一个项目等。甚至可以创建一个普通的WCF或SOAP服务层，仅此而已。这取决于你。

在那点上，您正在查看一个相当过程化的系统在服务层。这不是可怕的事情。将服务层视为MVC站点。您发送带有某种传入视图模型的请求，它以所有面向对象的精华进行其领域操作，并返回以某些XML表示形式的传出视图模型的视图。现在您有了重复模式。您的客户端应用程序只是您领域的巨大视图。它们越笨拙，它们就越可互换和可替换，这就越好。

这使您可以在服务边界处将各种“业务操作”封装在工作单元中。给定来自客户端应用程序的请求，要么整个过程成功，要么整个过程失败。用良好的错误处理和应用程序级错误/异常记录器将其包装起来，以便为您提供所有失败请求的详细信息。（想象一下，每个请求都可以序列化为字符串并包含在错误消息中。现在您拥有重建简单字符串中的错误所需的所有内容，而不是询问用户“您单击了什么？”以尝试重新创建错误。）

如果后端不与其他应用程序共享任何内容，并且每个应用程序都是完全独立的实体，那么您实际上不需要共享服务层后面的所有逻辑，而且完全有可能您不应该尝试进行任何重叠。如果服务后面的唯一内容是数据访问，那么您可以像您习惯的那样在客户端应用程序中保留模型和数据访问存储库，并使用内部引用和访问服务层的实现来交换存储库实现。正确抽象化的话，直接访问和服务访问存储库可以根据应用程序需要生活的位置轻松交换。当然，这有点偏向真正的持久性无关方法，这可能是危险的。需要考虑性能影响。后端的某些逻辑或工作单元可能会多次访问数据库以执行多个操作。如果在服务中发生这种情况，则每个数据库调用都会增加服务开销。因此，您需要根据具体情况进行处理。我想我可能在胡言乱语，所以要回到具体问题，这实际上涉及到一些关于您的领域的问题。您可以承受多少持久性无关？您的应用程序是否共享业务领域逻辑？您是否只需要访问服务后面的其他非数据库外部依赖项？没有通用的设计总是正确的答案。您可能最终会尝试各种设计并在适合您的开发人员和环境的设计上同化。