.Net Classes Best Practices

  • Thread starter Thread starter Hugh McLaughlin
  • Start date Start date
H

Hugh McLaughlin

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.
 
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.GetDate returns a DataTable, I
could simply use myDataGrid.datasoure = myComponent.GetData.

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
 
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.
Click to expand...

Let's emphasize a little more. The more you add to functionality that isn't
going to be used, the less reliable your application is going to be.
A lot of .NET gurus, MVP, authors sit around writing little piece of code
for books. magazines and small desktop problems...some might even do a
"LITTLE" consulting work for a company...but when it comes down to
*production* code and actually doing all of the coding and realizing how
hard it is to manage the layer approach that isn't even utilized, you need
to ask yourself if these Microsoft Super "lost" architects actually spend
their time actually maintaining the code itself.

In other words, most of the the n-Tier features are never practical in the
REAL world. All that money that's being spent on architecting a n-Tier
layer for the database could have been spend on just buying a SQL server
database and doing the port. That's how many hours(read MONEY) of design
work is needed for n-Tier...and guess what? This 2-second change for the
long term is NEVER realized cause they then blame the customer for not
including it in the specifications and then take 2 months to do a major
redesign anyway in order to implement it anyway...whew!!!! lots of savings
there....

Oh and guess what? Remember ASP and COM object...all that separation stuff
in the old world of VB6. You have to use InterOp and that's SLOW. So all
this B.S. about porting never comes true with the NEXT BIG thing cause the
THING is SO DIFFERENT anyway, the legacy code will have some major
disadvantage anyway as someone trained in the legacy code is needed to
support it.

Oh and one more things, since you build WEB apps, consider asking yourself
what TRUE and REAL business advantage it will be to have the exact same
thing on Windows? and is this FEATURE that windows offers a critical
business feature that can't be done some way on the web? In other word, take
away this feature that windows offers and see if anyone really needs it ir
misses it. (Delayed order submission when disconnected from the internet or
the database? Is that really going to make difference in the quartely
statement when the saleperson is just going hook up at the end of the day
anyway? If the customer wanted it that fast and wanted real-time quotes,
they should order on the web in the first place!!)

You know things are so much easier to develop once you standardized on a
single browser, like IE versus Netscape. Even on customer support that's so
much easier. Now you got these same n-Tier, OOP guys forgetting that
important lesson....Remember to add in all the additional support and
maintenance costs in creating both a Windows and Web app that target the
same info.
 
Back
Top