DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Why Stateful and Local Anti-facades are KISS

Why Stateful and Local Anti-facades are KISS

adam bien user avatar by
adam bien
·
Aug. 03, 10 · Java Zone · Interview
Like (0)
Save
Tweet
4.83K Views

Join the DZone community and get the full member experience.

Join For Free

The Gateway exposes rich and persistent domain objects directly to the presentation logic. Because the domain objects are well encapsulated already - it is rather an advantage, than a shortcoming. Because of simplicity and built-in aspects, an EJB 3.1 happens to be the simplest and leanest candidate for a Gateway implementation.

Why local (to JSF 2, Wicket or a Fat Client)?

  1. Rich domain objects (JPA 2) contain business logic per definition. A call to method can change the state not only of the target entity, but of the whole connected graph. In the local case the EntityManager will correctly recognize the changes and compute deltas (change sets) and persist all changes at the end of the transaction. In remote case you will have to implement the same functionality - what is actually duplication.
  2. In local case you don't have to care about lazy loading. The entities gets just loaded on demand.

Why stateful (means: keeping the entities attached between requests)?

  1. In complex scenarios the data synchronization between layers becomes a challenge. If you keep you entities managed between requests, there is nothing left to do. You can even bind them directly to the UI - and it will still work.
  2. For every request you will have to build the domain graph again and again. This is not only complex, but it does not necessarily scale better, than a stateful solution

Local, stateful facades are not necessary the silver bullet, but the resulting architecture is very lean. It mainly consists of only domain objects, with a few Gateways.

Before you start prematurely "improving" the scalability and start with bloated applications, it is more reasonable to concentrate on the core business logic and stress test continually the application. In some cases a stateful architecture wont't scale. In this case you will have to provide the synchronization, delta-computation afterwards - with demand documented with stress test results. [See Gateway, page 101 in "Real World Java EE Patterns Rethinking Best Practices" book for more in-depth discussion]

From http://www.adam-bien.com/roller/abien/entry/why_stateful_and_local_anti

KISS

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Internal Developer Platform in Plain English
  • Blocking Ads on Your Network Using Raspberry Pi 3 + Fedora + Pi-hole
  • Making Your Own Express Middleware
  • Reactive Kafka With Streaming in Spring Boot

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo