Re: Questions for Desginers\Archiects

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Starting with the database isn't a bad idea. After all, it's always about
the data. Sometimes designing the database will suggest design ideas for the
app to you!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.


"NH" <NH@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:49B08DE5-576A-4FD8-89CC-09EEA7A80531@xxxxxxxxxxxxxxxx
Thanks for the great insight Kevin, much appreciated.

Yes I have jumped into specifics too quickly on one previous project and
now
I find myself thinking "if only I designed it in this way". While the
project
was a very good success here certain parts of the system were designed
without thinking about the bigger picture and possible issues about
expanding
the system etc. I've learned from that.

I am familiar with the design you mention, I suppose I would just love to
see a small application that embodies best practice. I have looked at the
ASP.Net Time Tracker Starter Kit, its probably not a good sign when I
found
that complicated. I am very strong on database stuff so I tend to design
with
the DB as the main thing, now I realise I need to get out of that mindset
and
start putting the business logic where it should be.

Thanks for the links...

N

"Kevin Spencer" wrote:

Hi NH,

I read as much as
I can about designing systems (and I cant really find any decent books)
I
dont have anyone to discuss the best approach or what would be best
practice.

You're attitude is commendable. More time spent up front in learning how
to
properly design applications, and more time spent in the design process,
ultimately mean much time saved over the long haul, both in current
development, and in future maintenance and upgrade.

Here's an excellent (and free) resource for all types of subject matter
in
this domain:

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

I notice that you seem to be thinking a bit too specifically when it
comes
to the design of your current project, and about design in general. For
example, take the following question:

How can I handle this business logic in
asp.net, create some classes and use datasets so the application itself
handles the logic? And then use SP's for purely retrieving data?

My personal approach is to not think too specifically about a problem,
but
to think about the principles involved. There are many good approaches to
design and architecture, and quite a few patterns out there, but the good
ones are all based upon the same principles, and grow out of them.

In the above question, you ask about a specific technology (ASP.Net), and
2
specific tools (DataSets and Stored Procedures). This is a fairly common
mistake, and I've been guilty of it myself, which is why I'm sharing what
I've learned with you. By being so specific, you limit yourself to
thinking
only about a particular environment (such as ASP.Net) and the
characteristics of the specific tools. You ask whether Stored Procedures
should be used for only a specific purpose. A better way to state the
question might be:

How should business logic be handled in an application, and what sort of
business classes might help to connect the data in the database with the
user interface in such a way as to minimize the amount of change needed
when
a change is necessary in either the interface or the data? To what extent
should any database member modify data, handle data validation and
protect
the integrity of the data in the database?

Now, that's just an example, but notice that I avoid specifics. By doing
so,
I force myself to think about the whys and wherefores of the parts of the
application, and free myself to think of more alternative solutions.

ASP.Net and, for example, Windows Forms, have quite a lot in common, and
quite a lot of principle is shared by both. One may apply the same
principles to both environments. Every application centers around data of
some sort. In every applicatioon, data is stored somewhere, whether
externally or internally. Every application manipulates that data and/or
changes it. Every application has an interface, whether it is a user
interface or a programming interface. Every application has business
logic
which enforces a set of rules concerning what should be done with the
data,
and how it should be done.

So, in effect, every application has data, process, and interface. Every
application has a set of requirements, a set of needs that it is designed
to
fulfill. Beyond that, things become increasingly specific. But I find it
useful to start at the most common level and work my way up (down?) to
the
specifics.

Now, for maintenance and extensibility, some separation is in order. By
loosely coupling these components, we eliminate dependencies, making it
easier to islolate and change any individual part without having to
rebuild
the whole app at one time. The wheels of a vehicle are not welded to the
axle; they are bolted. One can swap out a wheel without having to swap
out
the axle. By limiting wheels to a certain range of sizes, we gain the
ability to use the same wheel on multiple vehicles.

So, we generally start by separating out the 3 basic components of an
app,
data, process, and interface, and then begin to subdivy the components of
each one until we have a nice, modular, extensible architecture. Once you
have isolated each component, you can begin to think about the
requirements,
and what areas of responsibility each component needs to fulfill. At that
point, you begin to get a little more specific.

Remember that the requirements you are given may be more specific than is
useful as well. Try to think of the requirements in a more abstract way.
For
example, you mentioned that your next project is a "forecasting system."
You
may have been given a set of requirements such as "We need to be able to
gather weather information from the National Weather Service for the
greater
metropolitan area, and provide forecasts on our web site." But you need
to
break that requirement down. It may (and probably will) change at some
point
in the future. You might rephrase the requirement as "We need to be able
to
gather weather-related information from the best weather sources
available,
and provide that information in a variety of user and programming
interfaces, for a variety of purposes." Now, when you design the
solution,
it will be extensible, and if you design your components well enough,
isolating functionality into various categories that translate into
namespaces, classes, etc., you will be able to extend, re-use, and
maintain
a variety of apps with different combinations of those components.

If you can train yourself to think in this sort of way, and practice it,
you
will become a more powerful programmer over time. It's not just a matter
of
reading and studying, although those are indispensible. It is also a
matter
of practice.

Best of luck to you!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.


"NH" <NH@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:172E5541-F219-4273-8530-E625DE8A1408@xxxxxxxxxxxxxxxx
Thanks for the replies.

I think one of the reasons I have all these qyestions is that I am
building
these system on my own, I'm a one man team, so even though I read as
much
as
I can about designing systems (and I cant really find any decent books)
I
dont have anyone to discuss the best approach or what would be best
practice.

On the DAL I do have classes with statis members such as
DAL.GetUsers(), I
just call these things from the button click handlers.

I am beginning to realise Stored Procedures are limited, I have found
in
hard to maintain many SP's when business logic changes, and its
difficult
to
pass result sets between SP's etc. How can I handle this business logic
in
asp.net, create some classes and use datasets so the application itself
handles the logic? And then use SP's for purely retrieving data?

I am just about to begin another application project (a forecasting
system)
and I again will be the sole developer, Database developer, report
builder,
anaylst etc etc. So I am considering a new approach to building and I
dont
mind if it takes me twice as long to build, I would like to focus on
best
practice.


"Kevin Spencer" wrote:

Hi NH,

Good questions!

I create systems for a medium sized business's (200+users) using SQL
Server,
ASP.Net 1.1 and 2.0. Generally I am very good at database design and
development so I feel comfortable putting all of my Business Logic
into
stored procedures. Is this wrong?

It depends on what you mean by "Business Logic." Business logic is
different
from process that fetches data. It is process that enforces the
business
rules, and manipulates the data in an application. This includes logic
that
enforces how data interacts with other data, what it is used to
accomplish,
and so on. Defined as such, no, it should not be in Stored Procedures.
A
database is a storage for data. Business rules may change. One should
not
have to change the data layer to change the business rules of an
application.

Now although I have a number of classes to handle data access I dont
use
objects to handle things in my code e.g. I dont use a Customer
object
to
create a new instance of a customer or anything like that, my code
just
responds to clicks on buttons etc and executes SP's in response. So
I
do
feel
my data access layer is well abstracted away. But is this good
practice?

This depends upon the requirements of the application. If, for
example,
your
application is simply used as an interface to a database, no, it is
not
necessary to create a Customer class to work with Customer data. This
is
because the Customer data is treated as data, not as a Customer. SQL
Server
Query Analyzer is an example of such an application. It works with the
database, providing a user-friendly interface for working with the
data
and
the database itself.

Classes should reflect what they represent, in the context of the
requirements of the application. This is a principle of abstraction,
which
makes classes easier to work with because they are intuitive to the
developer. The classes themselves, their structure, provides clues to
the
developer about what they represent, and how they should behave and
interact
with one another.

Should I be using OO techniques in my app? Is that the recommended
way?

But of course! ASP.Net, and the .Net platform, are fully
object-oriented.
There are good reasons for this. OOP was developed to make the
complexity
of
programming simpler. Understand it, and use it correctly, and it will
save
you beaucoups time and trouble, and that means mo' money!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.





.

Quantcast