I guess the best way to think of it is in terms of seperation of layers.
For instance, let's say that I have a bunch of code in the code-behind
wherein I access a database and fill a grid. Now, if I want to change the
functionality of my query, I need to recompile that page and project and
re-deploy. This is because my presentation layer is in effect my dataaccess
layer. Now, if I do nothing in the presentation layer other than call a
function in my component, where myComponent.Get Date returns a DataTable, I
could simply use myDataGrid.data soure = myComponent.Get Data.
I can split the component up and put it on another server. I could
similarly have my component call a web service. So, my Component might
sit on a machine that has permissions to my DataBase server, but my web app
doesn't. It does however have access to this component or web service. I
can make my app more secure, more flexible, and depending on the situation,
get better performance. This is a very oversimplified example, but the
bottom line is the seperation of logic. Similarly, I could have my
Component App access a StoredProcedure to fill the datatatable which it
returns to the UI. Now, if I need to change something, I can simply change
the Stored Proc, realtime and implement my change transparently (well, as
transparently as you can). Now, I can give my StoredProc the permissions to
execute everything, but not the app itslef. I give the component
permissions (via the user credentials) to execute the Stored Proc(s) but
nothing else. Now, I have my logic split between the UI, my component and
the backend. I can create a very flexibily app here that's much more secure
than if I had to give my UI all the permissions.... Similarly, my component
could call a web service, which in turn calls the proc. This adds one more
layer of complexity, but it allows me one more level to secure the app, move
things around without disturbing the UI code etc.
Overall, if you have a stable system, each time you do a new build, you run
the risk of injecting a new bug. So, by using components and splitting
things up, you minimize what you can break when you make a modification.
Certianly you still break things, but the more things are components, like
LegoBlocks, the more flexibility you have. You have a slow server or one
that needs to grow.....move the .dll to a new server, change the reference,
and off you go.
I want to emphasize that there's more to consider depending on the
complexity of your app, but the 'short answer' of it is that the more you
break seperate your functionality, the more your app can bend to changing
needs.
HTH,
Bill
"Hugh McLaughlin" <an*******@disc ussions.microso ft.com> wrote in message
news:08******** *************** *****@phx.gbl.. .
Hello Everyone and thanks for your help in advance. I
have read a great deal about code reuse and the
development of the three-tier application, but am
somewhat confused on some issues and am looking for
input. I typically develop web applications in Visual
Studio 2003. Within the project, you can obviously
develop classes via code behind as well as other classes
not directly linked to web forms. However, it appears
that many examples actually recommend developing separate
class libraries that can be referenced from the web apps
as well as other applications. Could someone shed some
light on what is considered the best way to implement
this architecture. Any feedback is greatly appreciated.
Thanks.