June 16, 2006

Day 2 Session 4: Spring usage patterns

Principles

  • SoC
  • Multi–tier applications + layered applications

Component

  • loosely coupled components allow for re–use throughout the enterprise (I think this is a dodgy assertion; code re-use strategies are unsuccessful more often than not )
  • Spring perspective: components are just POJOs – technology neutral and therefore more likely to survive technology shifts. Still requires careful thought to achive reuse though

Container patterns:

  • Container provides the technical concerns which have been separated out from the functional components
  • DI/IoC container used to be clearly separated from app. server, but the distinction is becoming more blurred as spring picks up TaskExecutor, ShadowingClassLoader etc.

Component Interface

  • Component clients only access interfaces, not implementations
  • In spring can use a standard java class's public methods; no need for anything heavier weight unless the domain model requires it

Component Home

  • Locator for obtaining configured components
  • Largely just disappeared in Spring; DI means that clients don't need to be aware of the BeanFactory

Virtual Instance

  • Stub instances for entities that exist within the system that aren't needed right now; pooling, passivation, etc.
  • Spring support for this is more flexible (not restricted to session beans, can be any expensive object), but rarely used;

Interception

  • Container adds code to components by intercepting requests
  • Spring AOP is much more powerful

Lifecycle callback

  • have to be able to tell a component to change it's logical identity when used, also to clean up resources on exit
  • Spring lifecyle is much simpler than EBJ2: Just have startup and shutdown events, because most of the complexity went away with virtual instances

Spring API abstractions

  • ExceptionTranslator – convert checked or unhelpful exceptions into sensible ones
  • Template – manage acquisition and release of resources before and after business code
  • Exporter – Adapter to API–required classes e.g. the JMXExporter converts an arbitrary bean into an MBean
  • Proxy – Adapter from the (remote) return object of an API call, proxies the object and facades away checked exceptions and so on. (Exporter and proxy are 2 sides of the same thing)


- No comments Not publicly viewable


Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

Most recent entries

Loading…

Search this blog

on twitter...


    Tags

    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXX