Scribd
Upload
11 views1 page

Complete-Reference-Vb Net 79

Uploaded by

khalid
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
11 views1 page

Complete-Reference-Vb Net 79

Uploaded by

khalid
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Chapter 16: Interfacing with the End User

Overview
We have come a long way from Chapter 1, which discussed how important it is to separate application logic,
business logic, functionality, operations, and services from the user interface and its logic. Recall Figure 1−2,
which illustrated a bunch of related file transfer operations that operate in the background or behind the UI
components on a form. Most of this book is devoted to everything you need to know to build the logic in
first−class applicationsthe code behind. Now we have to put an interface on the application, so that our users
find the application useful, productive, and worth all the money you invested creating the product.

The reason I have delayed our study of Windows forms, visual controls, and UI components to the
second−to−last chapter is to stress how important this way of thinking (separation of business and user
interface logic) is. If you did not pick up on this theme in the opening chapters and throughout the book, then
it should become very clear to you in this chapter. It is the only way you can write software in the modern age
of distributed computing and component, widget−based, breakfast factory, software development. In fact, it is
the only way you should write software.

Waiting until this point in the book to get into forms and UI stuff is very different from how past VB books
were written, which typically launched into the subject from the get go. I read many of those book years ago,
and I always felt the authors were trying to get the readers up and running as quickly as possible (in some
cases, the franchise, the target readers, of the book merited this approach) before presenting a solid foundation
for writing code. Often, too much emphasis was placed on creating applications centered on forms that were
nowhere near those used in the real world"dragging and dropping" your way to a finished product in what
seemed akin to painting by numbers.

Note Another big payoff of first learning all you can about the .NET object model in the earlier chapters is
that you will be able to navigate around the forms and control classes like a pro. Visual controls and
components, such as forms and menus, are all objects, so you'll have an insider's understanding of how
their properties, identifiers, modifiers, and so on are defined, specified, and set.

I believe that the only thing this so−called rapid application development achieved was rapid application
frustration, because keen developers would lose interest due to the frustration of not learning what it takes to
write good software. Here is a good example from an e−mail I received while writing this chapter:

"I am depressed. I have made two classes. The first has the input fields and the second
accesses a table. But I don't know the way to link them and pass the data from the first class
to the second. I don't know how to create the container object that will contain the data. In the
first class I have created a table. Please help."

The problem with many developers (like this one) is that they spend too much time looking at cute UIs and
not enough time implementing the application.

It was also amazing to me, circa 1995, how completely different Delphi and VB books were from the new
Java books that were taking the world by storm. They hardly covered the UI subject, partly because Java's UI
technology was so bad in the first years that seven−day−old roadkill looked better on your desktop.

The world of software development has changed dramatically in the past few years. Before the advent of the
Web and distributed computing (which has your objects potentially spread all around the network),
programmers typically engineered heavy forms, forms in which most of the logic and functionality is packed

563

You might also like