Is this a good application Design?

  • Thread starter Thread starter Jay Balapa
  • Start date Start date
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
Jay Balapa said:
3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
Click to expand...

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.
 
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
Click to expand...

There are opposing schools of thought here. You will find advice telling you both ways, and some
saying to mix it.
 
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.
Click to expand...

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.
 
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.
 
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.
Click to expand...

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

Which is one of the many points I point to in the article (or PL/SQL, or whatever)
 
Eliyahu Goldin said:
With SQL Server 2005 you can write stored procedures etc. in c#.
Click to expand...

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.
 
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.
 
bradley said:
T-SQL is an excellent language for implementing business logic that is
tied closely to the database model or database processing. For
Click to expand...

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
Click to expand...

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

Data lookups are not business logic.
 
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
 
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.
 
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
 
Back
Top