J
Johnny Quest
I would really like someone to tell me why this makes sense? At work,
we are trying to create a single application at this point, but with
an eye towards gaining a higher level of reusability. It is an
Intranet application which requires a login.
Another individual has decided that the right way to build this
application is by building a dozen or so little applications,
something like this:
http://localhost/login (everything redirects here)
http://localhost/workorder
http://localhost/usersettings
http://localhost/users
http://localhost/fancyform
And so on...ad nauseam...all of these 'applications' deployed to
separate virtual directories, needs to act as though it were a single
application. That is, if I go from a page on:
http://localhost/usersettings
to a page on:
http://localhost/workorder
It needs to act as though they were a single application, navigating
seamlessly between them through a common menu system.
Of course, to do this will mean that we can no longer use in-process
session state management. That much is a given and seems not to be a
barrier to implementing this convoluted solution.
I can almost buy the separate login application so that as we develop
new applications they can leverage this functionality, but making each
page its own application seems kind of bizzare to me?
Another question I have is about namespaces and project folders and so
on. This individual has decided to go about it something like this:
/BalloonCompany/apps/web/TheApp
/BalloonCompany/apps/windows/AnotherApp
/BalloonCompany/components/web/onething
/BalloonCompany/components/web/anotherthing
/BalloonCompany/classes/people/users/appusers
/BalloonCompany/classes/people/persons
/BalloonCompany/data/thingee
/BalloonCompany/data/security/blah
There must be at least 3 dozen of these projects now. The namespace
*usually& matches the location in SourceSafe project folders (a good
thing), but some of these projects have ONLY 1 *.cs file or others
maybe have a single *.aspx file. Of course, to use any of these
'stand alone' pieces one is obliged to resolve the references as a
solution is being built.
This just seems like madness to me. I would say that not only is it
over-engineered, but its becoming increasingly confusing trying to
decide where to put new functionality. I know many of you will find
it hard to believe that a programming team of 4 would start off doing
development without an approved design, but you may assume that that
is the case here.
Can anyone help me compile a list of reasons why this might be a bad
design? Or is this the greatest thing since sliced bread and I'm just
an old washed up wannabe?
we are trying to create a single application at this point, but with
an eye towards gaining a higher level of reusability. It is an
Intranet application which requires a login.
Another individual has decided that the right way to build this
application is by building a dozen or so little applications,
something like this:
http://localhost/login (everything redirects here)
http://localhost/workorder
http://localhost/usersettings
http://localhost/users
http://localhost/fancyform
And so on...ad nauseam...all of these 'applications' deployed to
separate virtual directories, needs to act as though it were a single
application. That is, if I go from a page on:
http://localhost/usersettings
to a page on:
http://localhost/workorder
It needs to act as though they were a single application, navigating
seamlessly between them through a common menu system.
Of course, to do this will mean that we can no longer use in-process
session state management. That much is a given and seems not to be a
barrier to implementing this convoluted solution.
I can almost buy the separate login application so that as we develop
new applications they can leverage this functionality, but making each
page its own application seems kind of bizzare to me?
Another question I have is about namespaces and project folders and so
on. This individual has decided to go about it something like this:
/BalloonCompany/apps/web/TheApp
/BalloonCompany/apps/windows/AnotherApp
/BalloonCompany/components/web/onething
/BalloonCompany/components/web/anotherthing
/BalloonCompany/classes/people/users/appusers
/BalloonCompany/classes/people/persons
/BalloonCompany/data/thingee
/BalloonCompany/data/security/blah
There must be at least 3 dozen of these projects now. The namespace
*usually& matches the location in SourceSafe project folders (a good
thing), but some of these projects have ONLY 1 *.cs file or others
maybe have a single *.aspx file. Of course, to use any of these
'stand alone' pieces one is obliged to resolve the references as a
solution is being built.
This just seems like madness to me. I would say that not only is it
over-engineered, but its becoming increasingly confusing trying to
decide where to put new functionality. I know many of you will find
it hard to believe that a programming team of 4 would start off doing
development without an approved design, but you may assume that that
is the case here.
Can anyone help me compile a list of reasons why this might be a bad
design? Or is this the greatest thing since sliced bread and I'm just
an old washed up wannabe?