Questions for Desginers\Archiects

[Guest]

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

 

[Karl Seguin [MVP]]

Far too many .NET developers don't use proper tiering and oo design - sadly
because those concepts, though very old, are poorly understood. Can I flat
out say that your design is wrong? No (although some people would). Would I
develop it anohter way? Probably. Putting asside that I know little about
your project, your team and your requirement, stored procedures aren't
nearly as good at handling business logic as a rich domain layer is. They
are less readable, flexible and maintainable.

From your explanation, it doesn't seem like your DAL is abstracted at all
away. If you are opening connections and creating datasets/datareaders in
your button clicks, then there's no abstraction at all. You should atleast
rely on a class with static members to do this: DAL.GetUsers() this way
you could atleast swap out your DAL code.

You could always do more, like implement a provider model for your DAL,
truly abstracting it away. Use typed datasets so that you have something
that looks like a business layer and finally implement a true domain layer.

It isn't easy if you've never really done it. And, without a rich arsenal of
templates (for code generation) and other reusable code, it'll take a lot of
time upfront just to do (let alone figuring out hte quirks). If time's an
issue and it's something you are shipping out with a high quality
expectation, you'll probably be better off sticking to what you know best.
Down the road though, I hope you'll find a project that let's you explore
more traditional designs.

Karl

 

[Kevin Spencer]

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.

 

[Guest]

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.

 

[slagomite]

Check out this excellent article on layer abstraction, it discusses in
detail what business logic is, and where it belongs.

http://www.codeproject.com/gen/design/DudeWheresMyBusinessLogic.asp

Luke

 

[Guest]

thanks, I just read that already earlier today. I am familiar with the
concepts of tiers and layer abstraction, I'm just struggling with how this is
actually implemented. i.e. how the business logic layer (BLL) is implemented.

I have put my BLL in Stored procedures and this is limited, its difficult to
maintain and its not very intuitive. To implement the BLL in ASP.Net I assume
datasets are going to be a core object used?

 

[Kevin Spencer]

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.

 

[Guest]

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]

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.