Is this a good application Design?

[Chad Z. Hower aka Kudzu]

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...

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.

 

[Eliyahu Goldin]

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

 

[Guest]

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

 

[Guest]

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

 

[Chad Z. Hower aka Kudzu]

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.

Which is the overwhelmingly common scenario. What I described will work very well for you.

 

[Guest]

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

 

[Guest]

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.

 

[Robbe Morris [C# MVP]]

This has served me pretty well as a base design for
the software families I work on:


--
Robbe Morris - 2004/2005 Microsoft MVP C#
EggHeadCafe's RSS Search Engine
http://www.eggheadcafe.com/articles/multisearch/default.aspx

 

[Robbe Morris [C# MVP]]

http://www.eggheadcafe.com/articles/aspnet_how_to_create_object_oriented_applications.asp

--
Robbe Morris - 2004/2005 Microsoft MVP C#
EggHeadCafe's RSS Search Engine
http://www.eggheadcafe.com/articles/multisearch/default.aspx

 

[Kevin Spencer]

Pretty good stuff, Robbe!

--

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.