1

我刚刚开始研究如何为一个好的软件系统编写一个好的架构，并且我正在学习如何将高级组件分成层。在这种情况下，我尝试使用层，以便将每个层建模为一个黑盒。

我的架构中有 4 层：表示层、应用程序服务、业务逻辑和域/持久性。就我的问题而言，我们真的只需要关注演示和应用程序服务。

应用服务层将包含一个允许跟踪某个事件的服务。演示文稿将有几个视图，这些视图应该随着事件跟踪模型的变化而动态更新。从本质上讲，我似乎需要一种单向的变化传播机制。

由于我试图将这些层建模为层，因此我想限制每个层的外观对象之间的通信，并在必要时允许层聚合来自较低层的对象，尽管仅由接口知道。

我正在用 Java 编写这个应用程序，所以很明显要使用的是 Observable/Observer。但是，我不喜欢 Observer 接口的更新方法强迫您强制转换对象参数。我想通过为这个机制定义我自己的接口和类来解决这个问题。那么，问题在于应用程序逻辑将依赖于表示层的接口，这对于该架构来说是一个禁忌。这是否表明我应该首先尝试使用 MVC 建模并分层模型？或者使用应用程序服务层中已知的接口对每个视图进行建模会更好。这似乎是一个不好的地方，我被困住了。另外，我使用 View-Handler 设计模式来处理多个视图。

4

2 回答 2

0

Observer/Observable 通常不是最好的方法，尤其是在 Java 中，您必须从 Observable 派生，从而浪费了您的单一继承。正如您所讨论的，它还会导致耦合，这在跨层时很糟糕。

我更倾向于研究纯事件模型，服务提供了一种注册 EventListener 的方法，并在发生更改时触发一个 PropertyChangeEvent。

然后，服务层可以通知其他服务，或者通知表示层——它不知道也不关心，只有表示通过注册为侦听器的方式与服务耦合。

于 2010-07-07T19:59:18.000 回答
0

在我看来，您的问题与其说是关于发布/订阅，不如说是如何让各层进行通信。

简短的回答：

使用 MVC/MVP。查找有关它们的博客文章，下载源代码，并记住：如果您只有一把锤子，那么一切看起来都像钉子。意思是不要因为你拥有它们而应用它们，而是因为你需要它们而应用它们。

长答案：

如果您正在使用 Java，我建议您使用Head First Design Patterns，它可以让您了解模式中的思维方式。在您了解了设计模式之后，我认为您已经开始学习了，您可以看看Patterns of Enterprise Application Architecture。随意跳过 Head First，但如果你正在学习建筑，我强烈推荐这是一本非常好的书。

一旦你消化了 Fowler 的书，或者至少对 N-Tiered Enterprise Architecture 有了基本的了解，你就应该顺利上路了。

于 2010-07-07T20:38:05.220 回答