System Architecture Advice

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi All,

I have a web application with the usual 3 layers; presentation, business,
and DB.

We are just about to start work on a new project with a totally separate
presentation layer, but will use SOME of the existing business functionailty
and the same DB. Functionailty to be re-used will be a User object for
example.

I was going to introduce a 4th "common" business layer, which will sit above
the business layer for each site (existing and new). This common business
layer will contain the User object, with the other existing layers inheriting
this object.

Is this the best way to go about it?

If so - I have a problem with enumeration... say I have a UserType
enumerator in my User object. As soon as I move this to the new common
layer, it breaks my code in the presentation layer (because presentation
layer references existing business layer, but does not directly reference the
new common business layer).

Can anybody help with this?

Cheers.
 
Using inheritance is the approach that I would recommend. As you mentioned though, it will require you to reference the "common"
BOL in all of your apps. The common BOL should probably be a stand-alone class library so that multiple projects can reference it.

Is there a particular reason why this is a problem for you?

The other option is to simply rewrite all of the code, every time you need it, like in legacy apps. What a nightmare! ;)
 
Thanks Dave - great reply.

Below is a simple diagram of my ideal solution.

Pres A Pres B
| |
| |
Bus A Bus B
| |
---------- ----------
|
Bus Common

There is no particular reason why I didn't want to reference the common BOL
from all apps apart from I thought it would be a bit redundant having to
reference two BOL's instead of just the one, which then referenced the common
BOL. I also thought it would enforce better use of the different BOL's
amongst the developers.

I have managed to do this by marking objects in the Common BOL
"MustInherit". Bus A and Bus B then reference common ad inherit the common
user class. The only problem is the Enumerations which exist in the common
BOL is not accessible from any of the presentation layer apps.

The two options I see are to implement the solution you suggested Dave, or
to somehow get around the Enum problem.

Is there another way that I have not thought of?

Cheers
 
Since the presentation layer should probably be unaware of base BOL implementations, which I see is your ultimate goal, then you
could just implement different method overloads on BOL classes that call a protected (not sure of the VB keyword) method on the base
class and pass the appropriate enum value. This will abstract the presentation layer from the need to specify explicit enumeration
values.

This may not work with your design and use of the Enum in question. Here's an example of what I mean:

GUI --> BOL.DoSomethingCool() --> AbsBOL.DoSomething(Something.Cool)
GUI --> BOL.DoSomethingNeat() --> AbsBOL.DoSomething(Something.Neat)

Make sense?

If you truly require the "Something" Enum to be visible for use by the GUI, you can take the base type of the enum as a parameter
and cast it in the base implementation:

GUI --> BOL.DoSomething( 1 ) --> AbsBOL.DoSomething ( (Something) 1)
GUI --> BOL.DoSomething( 2 ) --> AbsBOL.DoSomething ( (Something) 2)

Of course, you can define your own enums in each GUI that you create. Unfortunately, it's not reusing any code and therefore may
become a maintainance nightmare:

GUI --> BOL.DoSomething( (int) GUISomething.Cool ) --> AbsBOL.DoSomething ( (Something) 1)
GUI --> BOL.DoSomething( (int) GUISomething.Neat ) --> AbsBOL.DoSomething ( (Something) 2)


I think your best bet for maintainance would probably be to add a reference in the presentation layers to the common business layer,
or go with the first solution I've offered above if it fits your use of the Enum.
 
Thanks Dave - I really appreciate your time.

Dave said:
Since the presentation layer should probably be unaware of base BOL implementations, which I see is your ultimate goal, then you
could just implement different method overloads on BOL classes that call a protected (not sure of the VB keyword) method on the base
class and pass the appropriate enum value. This will abstract the presentation layer from the need to specify explicit enumeration
values.

This may not work with your design and use of the Enum in question. Here's an example of what I mean:

GUI --> BOL.DoSomethingCool() --> AbsBOL.DoSomething(Something.Cool)
GUI --> BOL.DoSomethingNeat() --> AbsBOL.DoSomething(Something.Neat)

Make sense?

If you truly require the "Something" Enum to be visible for use by the GUI, you can take the base type of the enum as a parameter
and cast it in the base implementation:

GUI --> BOL.DoSomething( 1 ) --> AbsBOL.DoSomething ( (Something) 1)
GUI --> BOL.DoSomething( 2 ) --> AbsBOL.DoSomething ( (Something) 2)

Of course, you can define your own enums in each GUI that you create. Unfortunately, it's not reusing any code and therefore may
become a maintainance nightmare:

GUI --> BOL.DoSomething( (int) GUISomething.Cool ) --> AbsBOL.DoSomething ( (Something) 1)
GUI --> BOL.DoSomething( (int) GUISomething.Neat ) --> AbsBOL.DoSomething ( (Something) 2)


I think your best bet for maintainance would probably be to add a reference in the presentation layers to the common business layer,
or go with the first solution I've offered above if it fits your use of the Enum.
Click to expand...
 
Back
Top