After Hours

General discussion



By dilippillai ·
Tags: Off Topic
blog root

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Application Frameworks & Design Patterns

by dilippillai In reply to Pretentions

An Application framework should give us the following,<br />1. A way to segregate the 'custom/business' functional entities from the 'infrastructural' entities. This segregation should be inviolate. In other words if the framework is supposed to completely abstract the display/UI layer from the Business Logic layer, then no part of the Business Logic layer should have any requirement to define or instantiate anything that should be in the display layer. The framework should provide the plumbing so that BL can handoff to the UI Layer the information that should not identifiable from information from another BL entitiy.<br />2. The ability to plug-in functionality and allow for the scaling of one layer without affecting every other layer. So if we suddenly wish to provide the user to access a site from a client application, the implementation to support this should not require development in any other layer. Only the UI layer should change.<br />3. Assuming that the application being database agnostic is a good thing. And on this issue, I sit on the fence. The only development required to support a new db should be in the coding of an adapter that should only talk to a layer that abstracts the conversation between the BL and the BL data process layer. So if we could have adapters written to support LDAP containers, File System Containers, etc along with RDBMS. The BL Layer or the BL Data Process Layer should not change.<br />4. The actual placement of the layer elements should not always be a factor, nor should the process/data flow path be fixed.<br />

Collapse -

Application Frameworks & Design Patterns

by sbockelman In reply to Application Frameworks & ...

Description of Good n-Tier Architecture, but... a framework must do more (or less); <br />
see<br />
<br />
Frameworks should alleviate the burden of (re)creating the tedious and non-value-added parts of an application.  <br />
They should promote reuse and commonality by allowing code developed to
work with the framework to work in other applications using the same
framework.<br />
<br />
Frameworks can exist at various levels of abstraction and often
frameworks can be used in conjunction with other frameworks such that
some of the higher-level frameworks may become very concrete and much
less abstract than one might typically expect when using the term.<br />
<br />
For instance, within the company I currently work, we have a suite of
applications that can work both independently and as a unit, depending
on each of our customers' contracted services.  The suite is built
upon several well-known frameworks, such as J2EE and Struts, but is
also based on a suite-specific framework which provides several more
base classes, UI components, as well as AJAX code, which provides
termendous value and consistency when adding new features or new
applications to the suite.<br />
<br />
Isolation and Encapsulation of Concerns between tiers is a fundamental
principle of good application design and architecture, but it does not
adequately define or describe a framework.<br />
<br />
I suggest the author and other interested readers start with the wikipeda definitions: <br />
<br /><br />
<br />
and <br />
<br /><br />
<br />
and proceed (follow links) from there.<br />
<br />
<br />
P.S.  Where in the article are Design Patterns even mentioned?<br />
<br />
<br />

Related Discussions

Related Forums