Is this a good application Design?

  • Thread starter Thread starter Jay Balapa
  • Start date Start date
Michael Rodriguez said:
It's really a very fine line. If you have a system where hundreds of
users are crunching loads of data, which poison do you pick? Do you
do all the work in stored procedures (= database bottleneck), or do
you send everything back to the clients and distribute the processing
(= network bottleneck). We're still trying to figure it out...
Click to expand...

It depends on your system, and every sysetm is unique. No pattern will fit every system. What I
presented works well in my experience in 90%+ of systems. But each developer needs to evualate
the pattern and see if it is a good match for their system.
 
Where did you find in my post any advice for anything? You yourself write
"it's entirely possible to write stored procedures and other server-side
executables in CLR languages (including C# and VB.NET)". That's what I have
said too, nothing more.

Eliyahu
 
Datasets are not SQL...
So if you need to iterate through dataset objects, that just fine.
But don't pass things like "SELECT * FROM Customers WHERE CustomerId = 1"
from the presentation layer into the business logic. Instead you should do
the following: DataSet customerData = bll.GetCustomer(1); in the presentation
layer
 
I agree with it though, it's not the correct example.

In our case we need to pull the data from different tables, apply business
logic then pull data from other tables if required and insert in to
Temporary table then open cursor on Temporary table which returns data to
calling application.

Regards,
Mahesh
 
=?Utf-8?B?TWFoZXNo?= said:
I agree with it though, it's not the correct example.

In our case we need to pull the data from different tables, apply
business logic then pull data from other tables if required and
insert in to Temporary table then open cursor on Temporary table which
returns data to calling application.
Click to expand...

Which is the overwhelmingly common scenario. What I described will work very well for you.
 
Hi all;
Three tier architecture is very use ful for distributed application; You can
do one thing make some common classes for common functions and use sqlhelper
class as a DAL (Data Access Layer); dont customize sqlhelper class becauase
this can be use for all applications.
you can also customize your shared functions and pass sql statement as
string and can pass perameter according to condition; but you should use
stored procedure;


thankx
 
I agree. I am don't believe in putting business logic inside of the
database. Business logic belongs in the Business Logic Layer (BLL). In
addition, SQL commands and data access code do not belong in the BLL. A
entity should never know how to persist itself in the database. This is why
I am not a fan of Lhotka's CSLA framework. This breaks classic object
oriented programming rules.
 
"=?Utf-8?B?VG9ueSBQaGlsbGlwcw==?=" <Tony
(e-mail address removed)> wrote in
I agree. I am don't believe in putting business logic inside of the
database. Business logic belongs in the Business Logic Layer (BLL).
In addition, SQL commands and data access code do not belong in the
BLL. A entity should never know how to persist itself in the
database. This is why I am not a fan of Lhotka's CSLA framework.
This breaks classic object oriented programming rules.
Click to expand...

For differing views (ones I dont agree with, but you should always consider alternate views and
make your own choices)

Subject: Re: n-Tier Business App - Complex Logic
Newsgroups: microsoft.public.dotnet.distributed_apps



--
Chad Z. Hower (a.k.a. Kudzu)
"Programming is an art form that fights back"

Stuff: http://www.KudzuWorld.com
Blogs: http://www.KudzuWorld.com/blogs
 
Back
Top