Professional Web Applications Themes

Code behind with use of Abstract Factory? - ASP.NET General

Hi all! We're creating an administration for a web application. This includes severeal aspx pages. Our key entity in the web application is "Profile", which can have a certain type. Based on the profile type, the administration pages will have some small changes, such as displaying a few extra tabs, or maybe change the available choices in a dropdown. At my former company they implemented this sort of behavior by using a LOT of switch (c#) statements everywhere code flow was based on certain internal environment variables, which, over time got pretty messy to expand (emagine the implementation of a ...

  1. #1

    Default Code behind with use of Abstract Factory?

    Hi all!

    We're creating an administration for a web application. This includes
    severeal aspx pages.

    Our key entity in the web application is "Profile", which can have a
    certain type.
    Based on the profile type, the administration pages will have some
    small changes, such as displaying a few extra tabs, or maybe change
    the available choices in a dropdown.

    At my former company they implemented this sort of behavior by using a
    LOT of switch (c#) statements everywhere code flow was based on
    certain internal environment variables, which, over time got pretty
    messy to expand (emagine the implementation of a new profile type - we
    had to check every statement, which was a tedious task and made us
    develop a certain paranoira ;)

    Now, not wanting to repeat history, we're trying to find the right
    development pattern for our aspx pages. This is our current idea:

    1. We use a aspx page with code behind .cs file (lets call it
    EditSomething.aspx).
    2. The aspx page has several web controls, including tabs and buttons.
    3. Instead of putting profile type oriented switch statements in the
    code behind, we're think of introducing an abstract factory with set
    of classes corresponding to the amount of profile types. The abstract
    class defines the interface the subclasses will need to implement.
    3. On page load (or other places where needed) we will ask a static
    method on the abstract class to return the proper class based on
    profile type (and other information).
    4. On button clicks the actions and values are proxied to and
    processed by the same class.

    The pattern above is repeated on every apsx file in the
    administration. This ensures, that we know exactly where to expand our
    code, when expanding profile types (and more testable with NUnit, we
    suspect). And, when "forgetting" to implement a function, the compiler
    will tell us.
    The classes from the factory in return uses core classes, which is the
    business logic.

    Now, does anyone have comments on this sort of development pattern? We
    call the factory classes controllers, because they in fact, control
    the code behind (and partially inspired by the sound of
    Model-View-Controller design pattern :).

    I'd like to know whether others have found better, structured ways of
    reusing layout but still enabling certain changes - making the
    application behave in a certain way in every page, without making
    spaghetti code...

    Kind regards
    Christer
    Christer Guest

  2. #2

    Default Re: Code behind with use of Abstract Factory?

    Just speaking to the design pattern part, this sounds like a good candidate. Instead of having if-then's and switch/case's all over the place, you could base your entire app off of one interface - like ISiteLayout. And you have as many designs as you want, that all implement the ISiteLayout interface..

    So, once you figure out which class to instantiate (and it won't matter to the app, which class that is) - you can just use the interface at will. So if you have Admin, and General as classes that implement ISiteLayout, you could do either of these:

    ISiteLayout objMyLayout = new Admin();
    -or-
    ISiteLayout objMyLayout = new General();

    and then continue to use objMyLayout like normal..


    Back to the issue at hand, we've always done this by having a bitmask of what you are allowed to see (by section, for an application) - and a function to check. So we'd check if you are authorized to see a page, or whether to show nav - based on a setting for that section of the app. It's not as bad as what you described, you basically need to handle security at one place in the nav, and one place at the top of the page.


    "Christer" <com> wrote in message news:google.com...
    Hi all!

    We're creating an administration for a web application. This includes
    severeal aspx pages.

    Our key entity in the web application is "Profile", which can have a
    certain type.
    Based on the profile type, the administration pages will have some
    small changes, such as displaying a few extra tabs, or maybe change
    the available choices in a dropdown.

    At my former company they implemented this sort of behavior by using a
    LOT of switch (c#) statements everywhere code flow was based on
    certain internal environment variables, which, over time got pretty
    messy to expand (emagine the implementation of a new profile type - we
    had to check every statement, which was a tedious task and made us
    develop a certain paranoira ;)

    Now, not wanting to repeat history, we're trying to find the right
    development pattern for our aspx pages. This is our current idea:

    1. We use a aspx page with code behind .cs file (lets call it
    EditSomething.aspx).
    2. The aspx page has several web controls, including tabs and buttons.
    3. Instead of putting profile type oriented switch statements in the
    code behind, we're think of introducing an abstract factory with set
    of classes corresponding to the amount of profile types. The abstract
    class defines the interface the subclasses will need to implement.
    3. On page load (or other places where needed) we will ask a static
    method on the abstract class to return the proper class based on
    profile type (and other information).
    4. On button clicks the actions and values are proxied to and
    processed by the same class.

    The pattern above is repeated on every apsx file in the
    administration. This ensures, that we know exactly where to expand our
    code, when expanding profile types (and more testable with NUnit, we
    suspect). And, when "forgetting" to implement a function, the compiler
    will tell us.
    The classes from the factory in return uses core classes, which is the
    business logic.

    Now, does anyone have comments on this sort of development pattern? We
    call the factory classes controllers, because they in fact, control
    the code behind (and partially inspired by the sound of
    Model-View-Controller design pattern :).

    I'd like to know whether others have found better, structured ways of
    reusing layout but still enabling certain changes - making the
    application behave in a certain way in every page, without making
    spaghetti code...

    Kind regards
    Christer
    Frank Guest

  3. #3

    Default Re: Code behind with use of Abstract Factory?

    Thank you for your answer, Frank... how's life in the police squad? ;)

    "Frank Drebin" <com> wrote in message news:<rD03b.34376$news.prodigy.com>... 

    We do expect the forementioned "controller" factories to be different
    for each aspx page in the system. That is: A factory for
    editsomething.aspx and another factory for contentoverview.aspx. I see
    your point about it's "basically" what to show and what not, and that
    there are overlapping security checks that needs to be done on all
    pages - AND the security checks could be put in a more general place.
     

    Im not sure of what your point precisely is there. That the interface
    defines common functions, such as security checks? Or? I do agree that
    it wont matter to the app, however I think we intend to base our
    factories on inheritance instead of interfaces. Should be the same
    result, though.
     

    With "It's not as bad as what you described" are you referring to my
    future design, or to the design that was used at my former comany? In
    other words... what do you think is bad? ;)

    Kind regards
    Christer (and that's my real name :)
    Christer Guest

  4. #4

    Default Re: Code behind with use of Abstract Factory?

    I was talking more generally to the concept of having a class factory... in
    real life, I'm in the process of adapting a navigation approach I found on
    gotdotnet.com where pages are based off of a base class/page.. and you can
    then, on page load - do something like a VerifySec(curuser,cursecreq) - and
    if they are no good, show an Access Denied... and using this same type setup
    for how to show navigation.. because no matter what you do, you need to
    check privs for what navigation elements you need to show.. and you also
    need to make sure they can't manually navigate to the page...

    When I was saying "bad as it seems".. I was talking about our current
    implementation (which is somewhat like your old implementation) - where
    there is security checks for each navigation element (and that is done in on
    place) - and we also, at the top of each page call a method to make sure you
    have access to the page..

    So in short, that seems to be the way to do, regardless of the language..

    "Christer" <com> wrote in message
    news:google.com... 
    news:<rD03b.34376$news.prodigy.com>... 
    >
    > We do expect the forementioned "controller" factories to be different
    > for each aspx page in the system. That is: A factory for
    > editsomething.aspx and another factory for contentoverview.aspx. I see
    > your point about it's "basically" what to show and what not, and that
    > there are overlapping security checks that needs to be done on all
    > pages - AND the security checks could be put in a more general place.

    >
    > Im not sure of what your point precisely is there. That the interface
    > defines common functions, such as security checks? Or? I do agree that
    > it wont matter to the app, however I think we intend to base our
    > factories on inheritance instead of interfaces. Should be the same
    > result, though.

    >
    > With "It's not as bad as what you described" are you referring to my
    > future design, or to the design that was used at my former comany? In
    > other words... what do you think is bad? ;)
    >
    > Kind regards
    > Christer (and that's my real name :)[/ref]


    Drebin Guest

Similar Threads

  1. Designer: Collection of abstract objects
    By Joel G. in forum ASP.NET Building Controls
    Replies: 1
    Last Post: March 3rd, 07:54 PM
  2. Abstract Usercontrols
    By tobiwan_kenobi in forum ASP.NET Building Controls
    Replies: 0
    Last Post: June 2nd, 11:05 PM
  3. Abstract class
    By eussam in forum Macromedia Flash Actionscript
    Replies: 2
    Last Post: February 15th, 04:38 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139