Each html element is a object with methods and properties there is little
difference there. but I think we are getting off topic, My point is that
controls don't always do as you want, sometimes there are very quick and
do the job well, some times you spend so much time fiddling with they to
get what you want, I find it better to create what you want by spitting
html. I tend to design my database well so that each table or group of
tables represents a object and following the relation ships of the
database I can navigate though my objects to get what data I need. For
example a customer object would represent a customer table in the DB. Each
instance of the object would be a record of that table, that customer
record can in turn call a invoice object that would represent a linked
invoice table. This I used to do in Classic ASP using COM+. To think that
OOP is something new to Classic ASP developers is not so, although not all
asp developers may take such a approach. To me this is the real Idea of
OOP is to make each entity a Object with properties and methods and
collections. Properties usually relate to the fields of the table the
object represents, methods usually change the the data and collections
hold child objects that represent child table records.
<snip>
First, you don't seem to understand the difference between
pseudo-object-oriented programming technology and true object-oriented
programming technology, and the difference is significant. For example, true
OOP employs inheritance, which is a powerful tool for obtaining code
maintainability and reusability. True OOP also includes encapsulation, which
enables objects to fully control access to their members. There are many
other aspects of OOP, the .Net platform, and managed code and languages that
make it extremely powerful and productivity-oriented.
In addition, there is more to ASP.Net than the programming platform it is
written on. ASP.Net has a structure that is very powerful and enhances
productivity immensely when it is fully-leveraged. This structure, and the
power of OOP come at a cost. It is not something one can easily or quickly
master. It requires an up-front investment of time in study and practice.
Such abstractions as the Provider Pattern and various other patterns and
practices can, over time, enable a developer to perform twice the work in
half the time, to produce solid, reusable, easily-maintainable software that
requires much less maintenance, and is much more reliable than software
written using classic ASP and COM.
These claims are not matters of speculation. They are supported by a large
volume of work which has been done by many developers using the technology
over a number of years, including my own. I have used ASP.Net since it first
emerged, in fact, since it was in its' initial version beta. And from my own
experience, it took me years to fully realize and leverage its' power. That
is not something which can be done by reading some Getting Started articles,
Quick Starts, and tutorials.
That said, a developer has to make a living. One has to produce something to
make a living. The art of programming entails a constant process of
compromise, between what can potentially be accomplished with unlimited time
and resources, and what can actually be done with limited time and
resources. I have never been able to create the perfect software, nor to
take advantage of every possible benefit available in a technology in doing
so, although I have learned to work as much more and sleep as much less as I
possibly can. The "fish or cut bait" moment looms ominously in every
project.
Most projects, and the prospect of learning many new technologies often
reminds me of an elephant that needs to be eaten. To think about eating the
entire elephant is highly likely to prevent one from taking the first bite.
But perfection is not something to be attained; it is something to be
approached. Regardless of whether or not it is impossible to eat an
elephant, it is certainly possible to begin to eat one. The process of
eating is simply an iterative process of taking one bite at a time. Taking a
single bite of anything is a trivial task.
In conclusion, my aim is not to discourage. The question here, of whether to
use Controls, or to simply output HTML, is not an ultimate issue. It may be
a pragmatic issue for the time being, depending on one's circumstances. In
other words, it is a decision to be made for the present situation, and need
not have any influence on future decisions. Each bite is taken in the time
frame of that bite. Each development decision is made in the time frame of
that project. A developer's technique evolves over time, as the developer
learns and practices the art.
So, if it seems inconvenient to use any or all of the ASP.Net suite of tools
and technologies (in this case), if one feels that it is necessary to forego
the employment of some seemingly intimidating (at the moment) process in the
interest of getting the current job done, this is what one must decide. That
decision may be for the best at any given time, and as a matter of practical
experience, it is a decision which we all must continue to make for just
about any project, for the length of our careers.
--
HTH,
Kevin Spencer
Microsoft MVP
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net