Is this a good application Design?

J

Jay Balapa

Hello,

Currently my application has three tiers-

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in this
tier. This tier exclusively gets DataViews/ Arays/Lists as input. Outputs
are string objects with SQL Statements or just paremeters with
dataconnection key.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is absolutely no
UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables. There is
just one DatabaseGateway class which does all the functionality.

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.


I have been reading up on Rockford Lhotka's business objects and I just feel
that his framework is unnecessarily complex. I just dont see the need to
hold these intermediate Business Objects.



Thanks for your responses.
 
J

Josh

Your SQL should be in the Business Layer. The presentation layer should not
make or provide decisions on how data is collected ( that what tables / view
or columns are used ) as that is a business rule.
 
J

Jay Balapa

Josh,

Thanks for your response.

SQL most of the time is in the Business layer.

Sometimes I need to iterate Datarows in a Datagrid. In those cases I make
that exception.
 
B

bradley

If you want to do away with the complexity of the business objects, then
consider moving this business logic to the database as stored procedures and
triggers.
 
K

Kim Quigley

I wasn't aware that putting SQL in the business layer was a best practice. I
use SQL Server 2000 with stored procedures and my data layer accesses those
stored procedures. In the business layer, I have logical business objects
with properties and methods. The purpose of having a seperate data layer is
so that if your data source changes (for example: moving from SQL Server to
MySQL) then you only have to modify the data layer. The presentation and
business layers would be unaffected.
 
J

Josh

Keeping the layers truely seperate is difficult. I would suggest that even
if you have to itereate through a result set the SQL should be in the
Business Layer, pass your filter criteria to the business layer.
 
C

Chad Z. Hower aka Kudzu

Jay Balapa said:
3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.

Views are good - BUT with SQL Server result set based stored procedures are typcially better
because of SQL servers optimization techniques. Newer versions are adressing this, but as to how
much I dont know yet.
 
C

Chad Z. Hower aka Kudzu

Kim Quigley said:
I wasn't aware that putting SQL in the business layer was a best
practice. I use SQL Server 2000 with stored procedures and my data
layer accesses those stored procedures. In the business layer, I have

There are opposing schools of thought here. You will find advice telling you both ways, and some
saying to mix it.
 
C

Chad Z. Hower aka Kudzu

bradley said:
If you want to do away with the complexity of the business objects,
then consider moving this business logic to the database as stored
procedures and triggers.

There are of course many schools of thought, but personally I would never recommend that. If
you want my views as to why, you can read the link that I just posted.
 
C

Chris Simmons

I'm only starting on Lhotka's book (which Jay here mentions), but I
think the author recommends putting the data access in with the
Business Objects, but only as static CRUD methods. Then, the
assemblies are duplicated on the three "internal" layers (Presentation,
Business, Data Access). Unknown whether it is a best practice or not,
however it allows the actual "instantiatable" BOs to be fully
black-box, while still allowing the data access code full access to the
BO's internals ... at least how I'm reading it.

So far (about 80 pages in), the book is quite good.
 
S

Steve Walker

Chad Z. Hower aka said:
There are of course many schools of thought, but personally I would
never recommend that. If
you want my views as to why, you can read the link that I just posted.

Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.
 
C

Chad Z. Hower aka Kudzu

Steve Walker said:
Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

Which is one of the many points I point to in the article (or PL/SQL, or whatever)
 
C

Chad Z. Hower aka Kudzu

Eliyahu Goldin said:
With SQL Server 2005 you can write stored procedures etc. in c#.

Not quite... You can make calls to .NET procedures FROM STored procedures... But even then its not
a good idea in most cases to put your logic in SPs.
 
B

bradley

T-SQL is an excellent language for implementing business logic that is tied
closely to the database model or database processing. For example, imposing
data constraints or referencing a set of parameters against a lookup table
and returning a value. Of course, it helps is the developer is at least an
intermediate level SQL programmer and familiar with sub-queries, complex
joins, conditional grouping and where clauses, etc.
 
C

Chad Z. Hower aka Kudzu

bradley said:
T-SQL is an excellent language for implementing business logic that is
tied closely to the database model or database processing. For

I dont think you will find many that agree with you. C#, Java, anything is better at business logic.
example, imposing data constraints or referencing a set of parameters

Data level storage constraints are not business logic.
against a lookup table and returning a value. Of course, it helps is

Data lookups are not business logic.
 
J

Jay Balapa

moving this business logic to the database as stored procedures and
Problem with that approach is our application will have to support ACCESS as
well as SQL Server, in future we might have to deal with Oracle.

We program exclusively on interfaces and not on actual SQL or OLE objects.
By using simple Views we can mask the changes in underlying tables if
needed.

-jay
 
B

bradley

Data lookups are not business logic.

It can be if the business logic is implemented as meta data tables rather
than hard coded conditional branching and looping.
 
E

Eliyahu Goldin

I am not sure what are you getting to by insisting on moving the SQL to the
business layer. It looks to me like insisting on the dotnet framework to
belong to one layer only.

A database consists of tables, view, stored procedures, triggers etc. Tables
and views belong to data layer. Stored procedures and triggers can be in
either data or business layer. It won't hurt the SQL server if it will
contain elements of both levels.

Eliyahu
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top