代码之家  ›  专栏  ›  技术社区  ›  Mike

n层发布/订阅服务器设计问题

  •  1
  • Mike  · 技术社区  · 14 年前

    我正在研究如何编写一个好软件的良好体系结构 系统,我正在学习如何将高级组件分为多个层。 在本例中,我尝试使用层,以便将每个层建模为黑色 盒子。

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

    应用程序服务层将包含允许跟踪的服务 指某一事件。演示文稿将有几个视图 随着事件跟踪模型的更改而动态更新。固有地, 似乎我需要一个单向的变更传播机制。

    因为我试图将这些层建模为层,所以我想限制通信 在每层的外观对象之间,并在必要时允许层 从低一层聚合一个对象,尽管只有接口知道。

    我正在用Java编程这个应用程序,所以显而易见的是 可观察/观察者。但是,我不喜欢 观察器接口强制您转换对象参数。我想四处工作 通过为这个机制定义我自己的接口和类。问题, 那么,应用程序逻辑将依赖于表示的接口 层,对于这个体系结构来说是绝对不允许的。这是我应该尝试的标志吗 在最前面用MVC建模并将模型分层?或者是一个更好的主意 使用应用程序服务层中已知的接口为每个视图建模。 这似乎是个不好的地方,我被卡住了。另外,我使用视图处理程序设计模式来处理多个视图。

    2 回复  |  直到 14 年前
        1
  •  0
  •   Stephen P    14 年前

    观察者/可观察者通常 最好的方法,尤其是在Java中,你必须从可观察到的派生出来,从而浪费你的单个继承。正如您所讨论的,它还会导致耦合,当它跨越层时,这是不好的。

    我更倾向于研究纯事件模型,服务提供了一种注册事件侦听器的方法,并可能在发生更改时触发PropertyChangeEvent。

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

        2
  •  0
  •   Nate Noonen    14 年前

    在我看来,你的问题不是关于发布/订阅,而是关于如何让层进行通信。

    简短回答:

    使用MVC/MVP。查阅关于它们的博客文章,下载源代码,并记住:如果你只有一把锤子,那么一切看起来都像钉子。也就是说,不要因为你有模式而应用模式,而是因为你需要它们而应用模式。

    长回答:

    如果你在Java中工作,我建议 Head First Design Patterns 这将使你以模式的思维方式为导向。当你对设计模式了如指掌之后,我认为你现在正朝着这个方向前进,你可以看看 Patterns of Enterprise Application Architecture . 你可以先跳过这本书,但如果你想了解建筑,我强烈推荐这本书。

    一旦你读懂了福勒的书,或者至少对N层企业架构有了基本的了解,你就应该在前进的道路上走得很好。