Web architecture: MVC, Lazy initialization, Data transfer Objects, Open Session In View, is there a consensus approach?

Question

What flaws do you see in the following design, (and what would be your ideal architecture suggestion) for a typical web 3-tier application?

My current blueprint appr

Answer 1

Overall, it seems like a very good architecture. If you haven't already read it, I would recommend Martin Fowlers Patterns of Enterprise Application Architecture, which describe every subject in your question.

It is not clear from the question how large an issue you expect performance to be. In my experience, the performance bottlenecks are rarely where you think they are, and the sooner you find them, the easier it is to change the architecture to match.

You are right that testability is a major concern. I have used Martin Fowlers Passive View-pattern with some success. You should also take a look at Supervising Controller, from the same site.

Answer 2

Your above approach sound good.

But I think you should use UI-Beans. Of course this UI-Bean should be effectively immutable. As soon as it is created its state (and the encapsulated domain object) should not be changed.

Very simplified example:

class UIBean {
  DomainObject o;

  public String getDescription(){
     return trimToSummaryText(o.getDescription());
  }

  private static String trimForSummaryText(){
     ....
  }
}

Main pros:

• Template code tends to get cleaner and consise. Your Frontend-Developer will be happy about this.
• You don't tend to add frontend-specific helper methods to domain object classes.
• Grouping of different domain objects or view-beans is possible (ui-bean could have multiple fields). Encapsulation of lists is especially nice here.

Yes, it involves more java-classes for that. But this abstraction layer is nearly always fine as soon as your webapp and pages grow.

Answer 3

Super unless doing a SOFEA style front-end, which basically gets rid of the Controller part in the above architecture.

The front end is entirely contained on the client, which directly invokes REST or SOAP services returning JSON or XML. That seems to solve 100% of the problem with transforming domain objects for display!!!!

Perhaps, some suggest, the reason there's no clean solution to the N-tier architecture described above is because it's just plain wrong.

Links

1. http://raibledesigns.com/rd/entry/sofea_also_known_as_soui
2. http://www.theserverside.com/news/thread.tss?thread_id=47213
3. http://wisdomofganesh.blogspot.com/2007/10/life-above-service-tier.html

My current project uses a somewhat outdated N-tier architecture with Data Transfer Objects. The DTOs are unnecessary because the application is not distributed and never will be. The one benefit (which is not worth it IMO) of using the DTOs is that it forces a clean interface for the business methods - the View components can traverse the object graph on the pseudo-models however they wish - no lazy-initialization exceptions can be thrown.

One of the architectural pain-points I see in our architecture is that the business interfaces are two damned complicated. It seems as if we need a meta-business interface to encapsulate all of the little business interfaces. Indeed, this ends up happening where one service ends up calling three other services to do its work.

The controllers (in our case, Struts 1.2 Action classes) end up calling any combination of these ultra-fine grained or coarse-grained business components. In most cases, sadly, developers unwittingly or lazily code a variety of what should be business logic in the controller classes. I scream every time I look at one of these three-hundred line Action methods!!!!

The SOFEA approach seems to offer a much cleaner approach. AJAX allows even web applications running on browsers to have their front end coded using the proper MVC pattern, which is good for both users (by offering a more dynamic UI) and developers (allowing them to code proper MVC).

The UI is completely decoupled from the reusable business logic. Is the GUI thick or thin? It really won't matter -they'll be coded in basically the same way.

SOFEA / SOUI is new to me and I've never tried it, but I've been reading about it lately and I thought I'd share my thoughts.

Answer 4

Despite the question was last answered about year ago, perhaps the answer appears helpful to someone. Overall outlined by you architecture is fine, the only detail to add is: usually for passing data between layers (e.g. View and Service) instead of mentioned above UiBean-s so called DTOs (Data Transfer Objects) are used, these are plain POJOs with appropriate fields/setters/getters.

In one of previous/early versions of Java EE spec "DTO" term was mistakenly mixed with "ValueObject", though they have bit different purposes.

Hope, this helps.