Answer:
Use the "Code Behind" and "Self-Describing" techniques to
their fullest.
Build Towers, not Layers.
However, implement IDE changes to still keep the
advantages of layers.
- I am hoping that Microsoft will at least redo there Graphical Tool on Data
Access so that all I have to do is make pages dragging and dropping object
on the aspx page that will generate the "Code Behind" Page. However, I should
easily be able to modify the "Code Behind" Layer to suite my needs for Business
Logic and also Data Access Logic, like connecting to other databases using
that "Finely Tuned" code for using Stored Procedures of FMStocks. Heck, that
should be 1- 2 lines of code at most.
- I like this way as I view Database Driven Web Sites as mostly Functional
and less "component abstract" and WITHIN a 1 or 2 web pages.
Thus, I can take two (2) files, WebPage2.aspx and WebPage2.VB and drop it
into another customers web site without have to search for the code in "Current
Windows DNA Architecture" shown on the right.
- Why I like this is because I am constantly making changes to production
code, I also can separate web pages, and accordingly database access to like
Oracle, Siebold,.S Access or Excel (With larger web sites, data, of course,
can come from anywhere and everywhere)
- .NET architecture should be designed to make changes to Production Web
sites easy. Eliminating Spaghetti code is great but if I still have
Scattered Code than that just as bad. Since Microsoft is pushing "Self
Describing" data and the like, than this, IMO, is the way to go.
- Also, when a new programmers comes on board It will be much easier and
faster for that programmer to get up to speed.
- More Programmers can work on a site since they work on web pages (and the
code behind page) as opposed to 1 data access layer and 1 business object
layer ( or a few business modules) e.g. one web page can tie up several business
object thus tying up use of that business layer for other programmers.
Goto Page 3: VS.net IDE Changes