N 层发布/订阅者设计问题
我刚刚开始研究如何编写一个好的软件的良好架构 系统，我正在学习如何将高级组件分成层。 在这种情况下，我尝试使用层，以便将每个层建模为黑色 盒子。
我的架构中有 4 层：表示层、应用程序服务层、 业务逻辑和域/持久性。出于我的问题的目的， 我们实际上只需要关注表示和应用程序服务。
应用程序服务层将包含允许跟踪的服务 某个事件的。演示文稿将有几个观点，应 随着事件跟踪模型的变化而动态更新。本质上， 看来我需要一种单向变化传播机制。
由于我试图将这些层建模为层，因此我想限制通信 每个 Tier 的 Facade 对象之间，并在必要时允许一个 Tier 聚合来自较低一层的对象，尽管仅通过接口知道。
我正在用 Java 编写这个应用程序，所以显而易见的是要使用的是 可观察/观察者。但是，我不喜欢的更新方法 观察者接口强制您转换对象参数。我想解决 这是通过为此机制定义我自己的接口和类来实现的。问题， 那么，应用程序逻辑将依赖于演示文稿中的接口 Tier，对于这个架构来说是一个禁忌。这是我应该尝试的迹象吗 使用 MVC 建模并分层模型？或者这是一个更好的主意 使用应用程序服务层中已知的接口对每个视图进行建模。 这似乎是一个不好的地方，我被困住了。另外，我使用视图处理程序设计模式来处理多个视图。
I'm just getting into how to write a good architecture of a good software
system, and I'm learning how to separate high level components into Layers.
In this case, I'm trying to use Tiers, so as to model each Layer as a black
box.
There are 4 tiers in my architecture: Presentation, Application Services,
Business Logic, and Domain/Persistence. For the purposes of my question,
we really only need to focus on the Presentation and Application Services.
The Application Services Layer will contain a Service that allows tracking
of a certain event. The Presentation will have several views that should
update dynamically as the tracking model of the events change. Inherently,
it seems that I need a one-way change-propagation mechanism.
Since I'm trying to model these Layers as Tiers, I'd like to restrict communication
between Facade objects for each Tier, and when necessary, allow a Tier
to aggregate an object from one Tier lower, though only known by interface.
I'm programming this application in Java, so the obvious thing to use is
Observable/Observer. However, I don't like that the update method for the
Observer interface forces you to cast object arguments. I want to work around
this by defining my own interface and class for this mechanism. The problem,
then, is that the Application Logic will depend on an interface from the Presentation
Tier, a certain no-no for this architecture. Is this a sign that I should try
modeling with MVC fore-most and Layer the Model? Or would it be a better idea to
model each of the views with an interface known in the Application Services Layer.
It seems like a bad place to put it, and I'm stuck. Also, I'm using the View-Handler design pattern to handle the multiple views.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Observer/Observable 通常不是最好的方法，尤其是在 Java 中，您必须从 Observable 派生，从而浪费了单一继承。正如您所讨论的，它还会导致耦合，这在跨层时会很糟糕。
我更倾向于研究纯事件模型，其中的服务提供了一种注册 EventListener 的方法，并可能在更改发生时触发 PropertyChangeEvent。
然后，服务层可以通知其他服务，或者通知表示层——它不知道也不关心，并且只有表示层通过注册为侦听器的方式耦合到服务。
Observer/Observable is often not the best approach, especially in Java where you have to derive from Observable thus wasting your single inheritance. It also, as you discuss, causes coupling which is bad when it crosses tiers.
I would be more inclined to investigate a pure Event model, with the services providing a way to register EventListeners and firing, perhaps, a PropertyChangeEvent when the change occurs.
The Services layer could then be notifying other services, or notifying the Presentation layer -- it doesn't know and doesn't care, and only the presentation is coupled to the service by way of registering as a listener.
在我看来，您的问题与其说是关于发布/订阅，不如说是如何让各层进行通信。
简短的回答：
使用 MVC/MVP。查找有关它们的博客文章，下载源代码，并记住：如果您只有一把锤子，那么所有东西看起来都像钉子。意思是不要因为拥有模式而应用它们，而是因为需要它们而应用它们。
长答案：
如果您使用 Java，我建议 Head First 设计模式 这将使您适应模式的思维方式。在您了解了设计模式之后（我认为您现在已经开始了解了），您可以查看 企业应用架构模式。请随意跳过《Head First》，但如果您想进入建筑领域，我强烈推荐这是一本非常好的书。
一旦您消化了 Fowler 的书，或者至少对 N 层企业架构有了基本的了解，您应该就可以顺利上路了。
It seems to me that your question is less about Publish/Subscribe than it is how to get the layers to communicate.
Short answer:
Use MVC/MVP. Look up blog posts about them, download source code, and remember: if all you have is a hammer, everything looks like a nail. Meaning don't apply patterns because you have them, apply them because you need them.
Long answer:
If you're working in Java, I suggest Head First Design Patterns which will get you oriented to the way of thinking in patterns. After you have your head around design patterns, which I think you're on your way to now, you can look at Patterns of Enterprise Application Architecture. Feel free to skip Head First, but it is a very good book that I highly recommend if you're getting into architecture.
Once you've digested the Fowler book, or at least have a basic understanding of N-Tiered Enterprise Architecture, you should be well on your way.