https://luminoussheep.net/mediawiki/index.php?action=history&feed=atom&title=J2EE_Patterns_considerations 2026-04-16T19:03:46Z Revision history for this page on the wiki MediaWiki 1.43.8 https://luminoussheep.net/mediawiki/index.php?title=J2EE_Patterns_considerations&diff=68&oldid=prev 2021-09-14T21:33:18Z

<p>Created page with &quot;= Front end design considerations = === Session state on client === * only good for small amounts of data * avoids problem of replicating data across servers Implementation *...&quot;</p> <p><b>New page</b></p><div>= Front end design considerations =<br /> === Session state on client ===<br /> * only good for small amounts of data<br /> * avoids problem of replicating data across servers<br /> Implementation<br /> * HTML hidden fields<br /> * HTTP cookies<br /> * URI encoding<br /> Problems<br /> * Expose state/information to client<br /> * Data must be encoded as text<br /> * performance of large quantities of data<br /> <br /> === State on server ===<br /> * identify with session id<br /> * expire state on server shutdown/timout/explicit removal<br /> Multiple front end options<br /> * replicate state<br /> * use server affinity<br /> * store state on business tier/resource tier<br /> <br /> = Controlling access =<br /> == Embed guard in a view ==<br /> * Deny access to entire page (embedded guard tag only reasonable for few pages)<br /> ** use a central controller instead<br /> * Deny access to portion of page<br /> ** wrap restricted section in a tag<br /> <br /> == Guard by configuration ==<br /> * use features of servlet spec (2.2 but 2.3 more consistent) configure in web.xml<br /> * supports part view and entire view<br /> * unassigned = no direct access - may still forward to these pages<br /> * prevent direct access - put page in WEB-INF directory<br /> <br /> == Duplicate form submission ==<br /> * use controller servlet<br /> * synchroniser - deja-vu token<br /> ** set token in session and in page<br /> ** submitted token must match session stored token<br /> <br /> == Validation ==<br /> * Don&#039;t rely on client side checks - scripting may be turned off / circumvented<br /> Server side<br /> * form based - typically duplication of code<br /> * abstract types - separate validation model from application logic<br /> ** typically use metadata + constraints e.g. properties file<br /> ** may be slower and more complex - harder to maintain<br /> ** e.g. use factory for creating validators and xml config file<br /> <br /> == Helper properties ==<br /> &lt;jsp:setProperty name=&quot;bean&quot; property=&quot;*&quot;/&gt;<br /> * Sets matching name &amp; type to value automatically<br /> * Does _NOT_ set empty or null values =&gt; may need to manually clear<br /> * Check boxes only set items set =&gt; may need to manually clear<br /> <br /> = Business tier design considerations =<br /> == Storing state ==<br /> * If all traffic via web interface - state may be stored in web server<br /> * If via web &amp; thick client - consider state in middle tier<br /> * Consider clustering, server affinity, replication, persistence, traffic management<br /> <br /> == Session beans ==<br /> * dedicated to a single client<br /> * lives for duration of client<br /> * transient - lives with the container - not persisted<br /> * can time out<br /> * can participate in transactions<br /> * can be stateful or stateless<br /> <br /> * stateless - bean available as soon as method completes<br /> * Scalability issues typically due to miss application of stateful/statless beans<br /> ** use stateful for instances requiring conversation<br /> ** multiple calls resending/persisting state is often the wrong design<br /> <br /> == Control code in multiple views ==<br /> =&gt; changes impact multiple pages<br /> * Consolidate controle code<br /> ** introduce controller<br /> ** localise disparate logic<br /> For similar control in multiple places<br /> * view helper<br /> * guarding a view<br /> <br /> == Don&#039;t allow presentation tier objects into business tier ==<br /> * copy state into generic object to share<br /> * similarly for domain objects<br /> <br /> == Fat Controllers ==<br /> Too much logic in one place<br /> * factor out - delegate - use helpers<br /> <br /> == Helpers as scriptlets ==<br /> * try and create interfaces that expose intent - meaning (e.g. using custom tags)<br /> <br /> = Entity beans =<br /> * best suited to coarse grained logic<br /> * mapping to persistence data<br /> * transactional<br /> * multi threaded<br /> * long lived<br /> * App server provides: scalability, security, clustering<br /> * composite key<br /> ** must create separate object to represent key - serialisable<br /> ** attributes must be public - match name and type of entity bean<br /> ** should override equals and hash</div>

Martin