Code behind with use of Abstract Factory?

[Christer]

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 Drebin]

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" <wi******@hotmail.com> wrote in message news:7b**************************@posting.google.c om...
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]

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

"Frank Drebin" <no*****@imsickofspam.com> wrote in message news:<rD**********************@newssvr28.news.prod igy.com>...

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..
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.
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..
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.

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.

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 :)

[Drebin]

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" <wi******@hotmail.com> wrote in message
news:7b**************************@posting.google.c om...

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

"Frank Drebin" <no*****@imsickofspam.com> wrote in message

news:<rD**********************@newssvr28.news.prod igy.com>...

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..

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.

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..

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.

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.

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 :)