2

我有一个逻辑放置困境，但从这里开始是我的应用程序层：

  1. Presentation/UI 层（Web API 或 MVC，真的可以是任何东西）
  2. 服务层（该层总体上是精简的，并充当域模型和存储库层的导体）
  3. 领域模型（这一层并不贫乏，模型类中既有数据又有行为）
  4. 存储库

就目前而言，这些层设计得很好，流程很直观。但是，我需要将纯模型数据塑造成几个特定的​​ XML 文档，以通过 .xsd 模式进行验证（模型类不会1:1 映射 XML 文档，或者我可以直接将对象序列化为 XML）。对我来说，模型层不应该理解超出当前设计的形状或结构；这是更高层的责任。

我的第一个想法是提供整形和逻辑，以通过 ViewModel 类从服务层中的域模型数据创建这些 XML 文档，以返回一个级别。我在这里使用术语“ViewModel”来纯粹表示用于更高层或表示的成形数据。但是，我读到的所有内容都说服务层不应该包含 ViewModel：服务层应该返回 MVC 应用程序的视图模型吗？以及如何将复杂的 ViewModel 传递给 ASP.NET MVC 中的服务层？

好的，请稍等片刻，让我的 MVC 层包含 ViewModel。我有这个问题。拥有服务层的全部原因是能够充当应用程序的外观或入口点，从而允许多种 UI 类型（WinForms、WPF、WebForms、MVC、WCF 等）。我需要连接到服务层的任何UI 都可以使用 XML 整形逻辑。如果我把它放在 MVC/UI 层，如果我连接一个新的 UI，它就不再存在了。

现在我回到将 XML 整形类推回到服务层。我也不认为这些类应该在域层上，因为这不是业务逻辑并且指示格式类型：XML，我不想要。最后，我不能在像基础设施层这样的垂直层中引入这个逻辑，因为现在这个层必须理解我的领域模型并且像行李一样随身携带。

根据《专业 ASP.NET 设计模式》一书，在使用此体系结构时声明如下：“服务层的作用是充当应用程序的入口点；有时这被称为门面。服务层提供具有强类型视图模型的表示层，有时称为表示模型。” 我想将成形的类放在我的服务层中，因为这似乎是最合适的，而且我已经看到了这样的例子。

逻辑属于哪里？我想使用我的 1..n 个域模型类，使用各种数据构建一个 XML 文档，然后允许它对 UI/Presentation 层可用？谢谢！

4

1 回答 1

2

恕我直言，我会说您将这些 XML 整形类放入您的服务层的直觉似乎是正确的，它绝对不属于 UI 层，因为您需要它可用于不同类型的 UI。为它们创建一个单独的层似乎是一种矫枉过正。将它们放在您的数据访问类旁边似乎也不正确。

我认为你应该按照你的直觉去做这个。如果您在某个地方查看此代码并且您认为它不合适，那么您可以简单地将其移动到您认为合适的地方。事先好好考虑一下很好，但我会说不要挂断电话。开始编码，然后时不时地退后一步，寻找看起来不合适的东西。随着项目的形成，您必须不断地重构代码！

于 2013-01-15T04:32:53.557 回答