J2EE Patterns considerations

From sheep
Revision as of 21:33, 14 September 2021 by Martin (talk | contribs) (Created page with "= Front end design considerations = === Session state on client === * only good for small amounts of data * avoids problem of replicating data across servers Implementation *...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Front end design considerations

Session state on client

  • only good for small amounts of data
  • avoids problem of replicating data across servers

Implementation

  • HTML hidden fields
  • HTTP cookies
  • URI encoding

Problems

  • Expose state/information to client
  • Data must be encoded as text
  • performance of large quantities of data

State on server

  • identify with session id
  • expire state on server shutdown/timout/explicit removal

Multiple front end options

  • replicate state
  • use server affinity
  • store state on business tier/resource tier

Controlling access

Embed guard in a view

  • Deny access to entire page (embedded guard tag only reasonable for few pages)
    • use a central controller instead
  • Deny access to portion of page
    • wrap restricted section in a tag

Guard by configuration

  • use features of servlet spec (2.2 but 2.3 more consistent) configure in web.xml
  • supports part view and entire view
  • unassigned = no direct access - may still forward to these pages
  • prevent direct access - put page in WEB-INF directory

Duplicate form submission

  • use controller servlet
  • synchroniser - deja-vu token
    • set token in session and in page
    • submitted token must match session stored token

Validation

  • Don't rely on client side checks - scripting may be turned off / circumvented

Server side

  • form based - typically duplication of code
  • abstract types - separate validation model from application logic
    • typically use metadata + constraints e.g. properties file
    • may be slower and more complex - harder to maintain
    • e.g. use factory for creating validators and xml config file

Helper properties

<jsp:setProperty name="bean" property="*"/>

  • Sets matching name & type to value automatically
  • Does _NOT_ set empty or null values => may need to manually clear
  • Check boxes only set items set => may need to manually clear

Business tier design considerations

Storing state

  • If all traffic via web interface - state may be stored in web server
  • If via web & thick client - consider state in middle tier
  • Consider clustering, server affinity, replication, persistence, traffic management

Session beans

  • dedicated to a single client
  • lives for duration of client
  • transient - lives with the container - not persisted
  • can time out
  • can participate in transactions
  • can be stateful or stateless
  • stateless - bean available as soon as method completes
  • Scalability issues typically due to miss application of stateful/statless beans
    • use stateful for instances requiring conversation
    • multiple calls resending/persisting state is often the wrong design

Control code in multiple views

=> changes impact multiple pages

  • Consolidate controle code
    • introduce controller
    • localise disparate logic

For similar control in multiple places

  • view helper
  • guarding a view

Don't allow presentation tier objects into business tier

  • copy state into generic object to share
  • similarly for domain objects

Fat Controllers

Too much logic in one place

  • factor out - delegate - use helpers

Helpers as scriptlets

  • try and create interfaces that expose intent - meaning (e.g. using custom tags)

Entity beans

  • best suited to coarse grained logic
  • mapping to persistence data
  • transactional
  • multi threaded
  • long lived
  • App server provides: scalability, security, clustering
  • composite key
    • must create separate object to represent key - serialisable
    • attributes must be public - match name and type of entity bean
    • should override equals and hash