N-Tier Publish/Subscriber Design Problem

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 upd开发者_如何转开发ate 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.

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.

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.