Methodology

Re: Methodology

> I'd like to[color=blue]
> know if this is current practice or is there something better to use, and
> where can I find examples.[/color]

An excellent question, Mark. The answer to it depends a lot on how far you
want to go with ASP.Net and with programming in general. For example, if you
anticipate further expansion of your applications, learning more about good
OOP design and architecture would be a great idea.

First, let me recommend a great Microsoft resource, which is their "Patterns
and Practices" web site:

http://msdn.microsoft.com/practices/

This web site is a wealth of both information and useful code resources. I
think you will enjoy reading the various articles there, and may find that
some of the free libraries they offer will save you a lot of time.

From the code you've posted, I can see that you're doing well with the
syntax differences between ASP.Net and ASP, and seem to be getting familiar
with the ADO.Net family of data classes. It also seems to me however, that
your mindset remains procedural, rather than object-oriented. This is the
most important difference in the .Net platform.

Object-oriented programming came about in the natural evolution of
programming, as a result of, as with all other evolutionary steps in the
chain, the increasing complexity of applications and the systems on which
they run. A bit of history might be helpful here.

In the beginning, man created the 1 and the 0 (a little Biblical humor
there). Computers are called "computers" because they always have been
essentially, calculators. A processor does nothing but perform mathematical
operations. And the mathematical language of computers is binary (base 2),
with the numbers 1 and 0 representing "on" and "off" states in electrical
circuits. So, the first computers were programmed by feeding in a stream of
1s and 0s to the processor, and translating the binary output to something
meaningful to humans. While there were several different methods of doing
this, you are probably most familiar with the punch card. A punch card is a
card which has holes representing 0s. Where there is no hole, the number 1
is implied. To write a program, a programmer would take a stack of these
cards and punch holes in them to represent the numerical input to the
computer. The sequence of the 1s and 0s represented either commands or data.

Of course, it wasn't long before computers began to increase in capacity and
power, particularly with the advent of the microchip. So, the process of
writing binary code as computer instructions began to become
cost-ineffective. At the same time, it was observed that typically, these
instructions were combined and repeated in patterns to perform various
tasks. So, an intermediate, character-based, human-friendly programming
"language" was born: Assembler. This also precipitated the first compiler,
which would read Assembler code, and turn it into machine language (1s and
0s).

Again, computers continued to grow in capacity, speed, and power, and the
demand for even more powerful and complex programs resulted in the
development of the so-called "high-level" programming languages, such as C,
Fortran, Pascal, COBOL, and BASIC. These languages worked on the same
prinicple as Assembler. Assembler commands were often used in repeating
patterns to perform similar tasks. The idea of the higher-level languages
was to create languages which could contain functions that combined various
combinations of Assembler instructions without having to re-write those
Assembler instructions over and over, thus saving time. These languages were
also extensible, in that, various functions could be re-combined with other
functions to create new functions. Now the compilation process was a 2-step
process: The high-level code was compiled to Assembler, which was then
compiled to machine language (1s and 0s).

And yet, computers continued to evolve. A processor can perform exactly one
mathematical operation at a time. But some people got the very clever idea
of using a looping structure to "time share" the processor between various
tasks which could appear to run at the same time (by virtue of the sheer
speed at which the processor operates, like a movie). Multitasking computers
were born, and the multitasking "loop" structure was hidden inside the
Operating System. but programs could also be multi-task programs, each using
a set of its own (hidden) loops to share its share of the processor between
various tasks. Now, the world of programming took on a level of complexity
that could boggle anyone's mind. Loops within loops within loops... what a
tangled web we wove!

This was the origin of object-orientation. One of the principle aspects of
OOP is to hide complexity that is not necessary to be known to the
developer. This is done by means of a couple of the pillars of OOP:
Abstraction, and Encapsulation.

Abstraction is a term for a way of thinking about things in a very human
way. A program is nothing but process and data. But so is everything else in
the universe. To "open a Connection to a database" is actually a process
which involves putting together data in a useful way that can be used to
communicate between one application (process) and a database application
(another process). So, rather than thinking about all of the complex work
involved in the process, it is encapsulated into an object, called a
Connection.

The difference between a class or object and a function is that a function
has data that is stored within the function for the lifetime of its use
(while it is running), and is in essence simply a process, or a sequence of
instructions. A class or object can contain both process and data, and can
expose its data to other objects. In addition, it does not "run," but simply
"exists." It has functiions or processes which *can* run when called upon to
do so. But it must be explicitly created, and explicitly destroyed, whereas
a function's lifetime is from the time it is called to the time it finishes
running its process. It is a subtle but significant difference.

Encapsulation is the ability of a class or object to share or hide data, in
essence hiding complexity which is only useful to itself, and exposing a
relatively simple "interface" of data (fields and properties) and process
(methods, another name for functions, but within the context of an object).
A car has a complext engine which performs the actual work, but this is
hidden under the hood. The driver sees only the steering wheel, gear
shifting controls, brake, gas pedal, etc., making it easy to use a car
without knowing how it works.

The difference between a class and an object is that a class is a pattern or
design for objects. An object is an "instance" (working copy) of a class.

There's a good bit more to it than that, but I'm hoping to give you enough
to get you interested and started, and let you take it from there.

The beauty part is that one can design one's own classes, just as one can
design car or truck engines by combining various engine parts together in
different configurations. Once you develop a good set of configurable (or
"extensible ") classes, you can re-use them in various applications which
perform similar work, without having to write them all over again.

Getting back to the code you posted, you may have noticed that similar code
appears throughout your application. The process of opening a Connection and
fetching data, when using the same database or data source, is almost
identical. The classes of the .Net CLR are designed like engine parts, to be
useful in a large variety of configurations, to connect to any kind of data
source. But *you* Mark, are only connecting to one. So, you can create your
own "Database tier" of custom classes which perform all of these sequences
in the same way without having to rewrite all that code over and over again.

If you want to expand your enterprise, you can get even more
compartmentaliz ed, by creating a business tier, which performs operations
"under the hood" without having any user interface, and a "presentati on"
(user interface) tier, which exposes the business objects in a user-friendly
way. This way, you can create, for example, another interface for the same
type of applications, exposed as a Windows Form executable, or perhaps a Web
Service.

At any rate, the link I posted should give you a lot of useful information,
and a lot to think about, as well as some really nice, pre-built libraries
for implementing various common "patterns" of applications.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.


"Mark A. Sam" <msam@Plan-It-Earth.Net> wrote in message
news:uGGcxm3TGH A.4976@TK2MSFTN GP11.phx.gbl...[color=blue]
> Hello,
>
> Thanks to members of this fourm, I was able to get this method to work to
> write a record to an Access DB from the fields on a webform. I'd like to
> know if this is current practice or is there something better to use, and
> where can I find examples.
>
> Thanks for your help and God Bless,
>
> Mark
>
> Dim connectString As String = "Provider=Micro soft.Jet.OLEDB. 4.0; Data
> Source=" + Server.MapPath( "_database/DragonImporting .mdb")
>
> Dim myConn As New Data.OleDb.OleD bConnection(con nectString)
>
> myConn.Open()
>
> Dim strSQL As String = "INSERT INTO tblContactForm1 (txtName, txtCompany,
> txtPhone, txtEmail, txtComments, chkGrower, chkProduceDeale r,
> txtOtherCustTyp e, chkStandardBags , chkCustomBags,t xtOtherBags) VALUES
> (@txtName, @txtCompany, @txtPhone, @txtEmail, @txtComments, @chkGrower,
> @chkProduceDeal er, @txtOtherCustTy pe, @chkStandardBag s, @chkCustomBags,
> @txtOtherBags)"
>
> Dim myCmd As New Data.OleDb.OleD bCommand(strSQL , myConn)
>
> myCmd.Parameter s.Add("txtName" , Data.OleDb.OleD bType.VarChar). Value =
> txtName.Text
>
> myCmd.Parameter s.Add("txtCompa ny", Data.OleDb.OleD bType.VarChar). Value =
> txtCompany.Text
>
> myCmd.Parameter s.Add("txtPhone ", Data.OleDb.OleD bType.VarChar). Value =
> txtPhone.Text
>
> myCmd.Parameter s.Add("txtEmail ", Data.OleDb.OleD bType.VarChar). Value =
> txtEmail.Text
>
> myCmd.Parameter s.Add("txtComme nts", Data.OleDb.OleD bType.VarChar). Value =
> txtComments.Tex t
>
> myCmd.Parameter s.Add("chkGrowe r", Data.OleDb.OleD bType.Boolean). Value =
> chkGrower.Check ed
>
> myCmd.Parameter s.Add("chkProdu ceDealer",
> Data.OleDb.OleD bType.Boolean). Value
> = chkProduceDeale r.Checked
>
> myCmd.Parameter s.Add("txtOther CustType",
> Data.OleDb.OleD bType.VarChar). Value
> = txtOtherCustTyp e.Text
>
> myCmd.Parameter s.Add("chkStand ardBags",
> Data.OleDb.OleD bType.Boolean). Value
> = chkStandardBags .Checked
>
> myCmd.Parameter s.Add("chkCusto mBags", Data.OleDb.OleD bType.Boolean). Value
> =
> chkCustomBags.C hecked
>
> myCmd.Parameter s.Add("txtOther Bags", Data.OleDb.OleD bType.VarChar). Value =
> txtOtherBags.Te xt
>
> myCmd.ExecuteNo nQuery()
>
> myConn.Close()
>
>
>
>[/color]

Re: Methodology

Hello Kevin,

Thank you for the dissertation. I understood it all. I'm going to snip to
where I want to address what you wrote:


It also seems to me however, that[color=blue]
> your mindset remains procedural, rather than object-oriented. This is the
> most important difference in the .Net platform.[/color]

I'm not sure what you mean by procedural. I think I am object oriented
being an Access developer. I'm certainly event oriented. I look at an
object and want to know what events are available and maybe am prodecural
within the events. I don't see programming as a continuous pages of code
with subroutines and goto's.

[color=blue]
> The difference between a class and an object is that a class is a pattern
> or
> design for objects. An object is an "instance" (working copy) of a class.
>
> There's a good bit more to it than that,[/color]


That helped me a lot. I never had a clue what class was, and now it makes
sense, especially the inheritance part.


but I'm hoping to give you[color=blue]
> enough
> to get you interested and started, and let you take it from there.[/color]

You gave me a lot here. I don't think however that I'll get to intimately
involved the intricacies. I have a couple clients that want websites and
want me to do them, which is the only reason I am in it. After researching
and coming across Visual Web Developer, I saw that I could do what one
client wants and control the output easily with programming. I hope to get
funding to revamp the website you wrote for me years ago and is still
"truckin". When that happens, by programming days are done, because I will
hire it out to people who can do it better than me.

[color=blue]
>
> The beauty part is that one can design one's own classes, just as one can
> design car or truck engines by combining various engine parts together in
> different configurations. Once you develop a good set of configurable (or
> "extensible ") classes, you can re-use them in various applications which
> perform similar work, without having to write them all over again.
>
> Getting back to the code you posted, you may have noticed that similar
> code
> appears throughout your application. The process of opening a Connection
> and fetching data, when using the same database or data source, is almost
> identical. The classes of the .Net CLR are designed like engine parts, to
> be useful in a large variety of configurations, to connect to any kind of
> data source. But *you* Mark, are only connecting to one. So, you can
> create your own "Database tier" of custom classes which perform all of
> these sequences in the same way without having to rewrite all that code
> over and over again.[/color]

I guess I'm lost here. I don't write code over and over (other than DAO), I
write it usually once, then copy and past it then modify it. Are you saying
that creating a class is different or more advantageous?

[color=blue]
>
> If you want to expand your enterprise, you can get even more
> compartmentaliz ed, by creating a business tier, which performs operations
> "under the hood" without having any user interface, and a "presentati on"
> (user interface) tier, which exposes the business objects in a
> user-friendly way. This way, you can create, for example, another
> interface for the same type of applications, exposed as a Windows Form
> executable, or perhaps a Web Service.[/color]

It sounds like more than I want to tackle.

[color=blue]
>
> At any rate, the link I posted should give you a lot of useful
> information,[/color]

I'll definitely check it out and thank you for the time and effort in
writing this excellent reply.

[color=blue]
> and a lot to think about, as well as some really nice, pre-built libraries
> for implementing various common "patterns" of applications.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> Professional Numbskull
>
> Show me your certification without works,
> and I'll show my certification
> *by* my works.[/color]

Even so faith, if it hath not works, is dead, being alone.
Yea, a man may say, Thou hast faith, and I have works:
show me thy faith without thy works, and I will show thee my faith by my
works. James 2:17-18 (KJV)


Those that can do, those that can't become talk show hosts. Mark A. Sam

Re: Methodology

> I'm not sure what you mean by procedural. I think I am object oriented[color=blue]
> being an Access developer. I'm certainly event oriented. I look at an
> object and want to know what events are available and maybe am prodecural
> within the events. I don't see programming as a continuous pages of code
> with subroutines and goto's.[/color]

There is a subtle (but very important) difference between object-orientation
and pseudo-object-orientation. Functions, for example, may seem
object-oriented, as you treat the block of execution statements as if it
were a single execution statement. But true object-orientation includes
Encapsulation, Abstraction, Polymorphism, and Inheritance. I talked a bit
about Abstraction, Encapsulation, and Inheritance in my post, but if you
want to really dig into it, check out the following WikiPedia article, and
the links it references:



One thing that may help you to understand it better is to keep in mind that
object-orientation is an abstraction in and of itself. One way to understand
this is to look at Mathematics, which is, at the core of all of it, simply
counting. Addition is counting up; subtraction is counting down.
Multiplication is addition, and division is subtraction. Algebra
incorporates the concept of working with numbers which are not yet known, by
substituting variables for those numbers. Trigonometry takes this a step
forward, by including the concept of functions, which are an encapsulation
of multiple arithmentic operations into an aggregate type. And so on.

In other words, as I mentioned before, a processor can perform exactly *one*
operation at a time. So, underneath all programming is the sequential or
procedural process. It's all done by using nested loops. What
object-orientation is, is a way of thinking about all of this without
thinking about the deep underlying details, things which are not necessary
to think about unless you're building an Operating System, for example. It
introduces concepts, tools, and techniques for working with programs in a
way which is easier and more efficient for a developer to think about and
work with.

Object-orientation is a model of computing which is closer to the "real
world" that we are accustomed to operating in. It incorporates procedural or
sequential programming at various levels, as sequence and procedure are
important at a certain level. But it takes a lot of the lower-level detail
out of the picture, that detail which we don't need to be bothered with in
order to be an effective developer.

For example, we understand the concept of a vehicle in the real world. A
vehicle is a mechanical device that transports objects from one point to
another. It may have wheels, tracks, or a cushion of air under it to perform
the mechanics of movement. It may have any number of characteristics and
still be a vehicle. But "vehicle" is not a thing; it is a type (or "class").
It is a set of properties or rules which constitute our ability to identify
a mechanical device as being a vehicle.

A car, on the other hand, must have wheels. It is a vehicle, but it is not a
truck, a plane, or a hovercraft. Again, like "vehicle," car is an abstract
concept, a set of rules by which we can identify a type (or "class") of
mechanical device. A car is a vehicle, but a vehicle is not necessarily a
car. "Car" *inherits* "Vehicle".

Now, a 2006 Toyota Matrix XR is a further abstraction, and it is not yet an
actual car. Each type in the hierarchy further defines or specifies the type
it inherits from. In OOP, we might refer to it as
Vehicles.Cars.T oyota.Matrix.XR .2006.

To refer to an actual car, we would need to create an "instance" of a 2006
Toyota Matrix XR, with all of the options specified, and built to spec. The
car itself is an object, or an "instance" of a 2006 Totyota Matrix XR. It is
not a class, but an object.

I don't want to get too deep into the actual concepts of OOP (they are
Legion), but only to give you an idea of what the abstraction, and
derivative rules of OOP provide to the developer. In the .Net platform, for
example, every class has the ancestor of System.Object. All classes share
all of the code and characteristics of System.Object. From System.Object,
each successive generation in the hierarchy is more specific, and has more
characteristics , than System.Object.

Of course, this only touches on 2 aspects of OOP, Inheritance, and
Abstraction, But you should be able to see how just these 2 pillars of OOP
provide very powerful tools for the developer, in that a well-designed
hierarchy of classes makes incredible use of reusability, and presents
programming concepts to us humans in a much more intuitive and abbreviated
fashion. Read the Wikipedia article. I think you'll enjoy the heck out of
it!
[color=blue]
> I guess I'm lost here. I don't write code over and over (other than DAO),
> I write it usually once, then copy and past it then modify it. Are you
> saying that creating a class is different or more advantageous?[/color]

Exactly, my friend! Note what you said: "I... copy and past it then modify
it." Now, what happens when the underlying object model changes, or a bug
you were not aware of is suddenly made apparent? Well, you have to find all
of the places you copied and pasted code, and change each one. If instead,
you create a single class, and use it in all of your projects, all you have
to do is change that one class, and all of the projects are now up to date!
[color=blue]
> It sounds like more than I want to tackle.[/color]

I suppose it may. At times I have certainly felt a bit overwhelmed with new
technologies. But on the other hand, you may eventually find it so
fascinating that you can't stop! (like I do!)

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

"Mark A. Sam" <msam@Plan-It-Earth.Net> wrote in message
news:Ozse2%23BU GHA.4600@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> Hello Kevin,
>
> Thank you for the dissertation. I understood it all. I'm going to snip
> to where I want to address what you wrote:
>
>
> It also seems to me however, that[color=green]
>> your mindset remains procedural, rather than object-oriented. This is the
>> most important difference in the .Net platform.[/color]
>
> I'm not sure what you mean by procedural. I think I am object oriented
> being an Access developer. I'm certainly event oriented. I look at an
> object and want to know what events are available and maybe am prodecural
> within the events. I don't see programming as a continuous pages of code
> with subroutines and goto's.
>
>[color=green]
>> The difference between a class and an object is that a class is a pattern
>> or
>> design for objects. An object is an "instance" (working copy) of a class.
>>
>> There's a good bit more to it than that,[/color]
>
>
> That helped me a lot. I never had a clue what class was, and now it makes
> sense, especially the inheritance part.
>
>
> but I'm hoping to give you[color=green]
>> enough
>> to get you interested and started, and let you take it from there.[/color]
>
> You gave me a lot here. I don't think however that I'll get to intimately
> involved the intricacies. I have a couple clients that want websites and
> want me to do them, which is the only reason I am in it. After
> researching and coming across Visual Web Developer, I saw that I could do
> what one client wants and control the output easily with programming. I
> hope to get funding to revamp the website you wrote for me years ago and
> is still "truckin". When that happens, by programming days are done,
> because I will hire it out to people who can do it better than me.
>
>[color=green]
>>
>> The beauty part is that one can design one's own classes, just as one can
>> design car or truck engines by combining various engine parts together in
>> different configurations. Once you develop a good set of configurable (or
>> "extensible ") classes, you can re-use them in various applications which
>> perform similar work, without having to write them all over again.
>>
>> Getting back to the code you posted, you may have noticed that similar
>> code
>> appears throughout your application. The process of opening a Connection
>> and fetching data, when using the same database or data source, is almost
>> identical. The classes of the .Net CLR are designed like engine parts, to
>> be useful in a large variety of configurations, to connect to any kind of
>> data source. But *you* Mark, are only connecting to one. So, you can
>> create your own "Database tier" of custom classes which perform all of
>> these sequences in the same way without having to rewrite all that code
>> over and over again.[/color]
>
> I guess I'm lost here. I don't write code over and over (other than DAO),
> I write it usually once, then copy and past it then modify it. Are you
> saying that creating a class is different or more advantageous?
>
>[color=green]
>>
>> If you want to expand your enterprise, you can get even more
>> compartmentaliz ed, by creating a business tier, which performs operations
>> "under the hood" without having any user interface, and a "presentati on"
>> (user interface) tier, which exposes the business objects in a
>> user-friendly way. This way, you can create, for example, another
>> interface for the same type of applications, exposed as a Windows Form
>> executable, or perhaps a Web Service.[/color]
>
> It sounds like more than I want to tackle.
>
>[color=green]
>>
>> At any rate, the link I posted should give you a lot of useful
>> information,[/color]
>
> I'll definitely check it out and thank you for the time and effort in
> writing this excellent reply.
>
>[color=green]
>> and a lot to think about, as well as some really nice, pre-built
>> libraries for implementing various common "patterns" of applications.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> Professional Numbskull
>>
>> Show me your certification without works,
>> and I'll show my certification
>> *by* my works.[/color]
>
> Even so faith, if it hath not works, is dead, being alone.
> Yea, a man may say, Thou hast faith, and I have works:
> show me thy faith without thy works, and I will show thee my faith by my
> works. James 2:17-18 (KJV)
>
>
> Those that can do, those that can't become talk show hosts. Mark A. Sam
>
>[/color]