General discussion

  • Creator
    Topic
  • #2189271

    Pretentions

    Locked

    by dilippillai ·

    blog root

All Comments

  • Author
    Replies
    • #3069001

      Application Frameworks & Design Patterns

      by dilippillai ·

      In reply to Pretentions

      An Application framework should give us the following,
      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.
      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.
      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.
      4. The actual placement of the layer elements should not always be a factor, nor should the process/data flow path be fixed.

      • #3058163

        Application Frameworks & Design Patterns

        by sbockelman ·

        In reply to Application Frameworks & Design Patterns

        Description of Good n-Tier Architecture, but… a framework must do more (or less);
        see  http://en.wikipedia.org/wiki/Software_framework

        Frameworks should alleviate the burden of (re)creating the tedious and non-value-added parts of an application. 
        They should promote reuse and commonality by allowing code developed to
        work with the framework to work in other applications using the same
        framework.

        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.

        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.

        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.

        I suggest the author and other interested readers start with the wikipeda definitions:

        http://en.wikipedia.org/wiki/Application_framework

        and

        http://en.wikipedia.org/wiki/Software_framework

        and proceed (follow links) from there.

        P.S.  Where in the article are Design Patterns even mentioned?

Viewing 0 reply threads