Re: Questions for Desginers\Archiects

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.


"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



.

Loading