Re: Questions for Desginers\Archiects

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.


"NH" <NH@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1DF9E03A-5530-4509-A2E8-B09EE676BDF6@xxxxxxxxxxxxxxxx
Hi,

I'm looking for some opinions and advice on designing ASP.Net apps. Let me
explain my approach to how I currently design and hopefully you can give
me
some advice.

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?

In my asp code I create a number of classes which call the stored
procedures. Once the SP's are created and the classed are created I can
easily call them from my asp pages, so the data access layer is abstraced
away, as too is the business logic layer.

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?

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

Thanks
N


.