Is this a good application Design?

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

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[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

"bradley" <so*****@micros oft.com> wrote in message
news:%2******** ********@TK2MSF TNGP15.phx.gbl. .. 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.

"Jay Balapa" <jb*****@hotmai l.com> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

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.

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[Eliyahu Goldin]

Make your mind. Horrible language vs not terribly portable.

Eliyahu

"Steve Walker" <st***@otolith. demon.co.uk> wrote in message
news:ys******** ******@otolith. demon.co.uk...

In message <#L************ **@TK2MSFTNGP15 .phx.gbl>, Eliyahu Goldin
<re************ *@monarchmed.co m> writes

"Steve Walker" <st***@otolith. demon.co.uk> wrote in message
news:Iv******* *******@otolith .demon.co.uk...

In message <Xn************ **************@ 127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org > writes
>"bradley" <so*****@micros oft.com> wrote in
>news:#9******* *******@TK2MSFT NGP15.phx.gbl:> 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. Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

With SQL Server 2005 you can write stored procedures etc. in c#.

Not terribly portable though, is it?

--
Steve Walker

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

"Chad Z. Hower aka Kudzu" <cp**@hower.org > wrote in message
news:Xn******** *************** ***@127.0.0.1.. .

"bradley" <so*****@micros oft.com> wrote in
news:OX******** ******@TK2MSFTN GP10.phx.gbl:

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.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[bradley]

Look out! The barbarians are at the gate.

"Eliyahu Goldin" <re************ *@monarchmed.co m> wrote in message
news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

With SQL Server 2005 you can write stored procedures etc. in c#.

Eliyahu

"Steve Walker" <st***@otolith. demon.co.uk> wrote in message
news:Iv******** ******@otolith. demon.co.uk...

In message <Xn************ **************@ 127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org > writes

"bradley" <so*****@micros oft.com> wrote in
news:#9******* *******@TK2MSFT NGP15.phx.gbl:
> 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.

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

--
Steve Walker

[Chad Z. Hower aka Kudzu]

"bradley" <so*****@micros oft.com> wrote in
news:#o******** ******@TK2MSFTN GP14.phx.gbl:

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.

Yes, in that case it could be. In such cases I would put in the middle tier, not the database.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Chad Z. Hower aka Kudzu]

"Jay Balapa" <jb*****@hotmai l.com> wrote in
news:O$******** ******@TK2MSFTN GP10.phx.gbl:

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.
Then you should do it as my article says.
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.

Thats very good, but views wont do complex transforms. And the matter of views vs sps is a SQL
server one, SQL Server is not efficient with views, use SP "as views" when using SQL server.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Cor Ligthert]

Steve,

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.

Not better than English, what is called by non native English speakers often
a very poor language when it comes to symantics. Than it is in my opinion
even English with USA slang and therefore even worse.

Just my thought about it.

Cor

[Nick Malik [Microsoft]]

Hi Jay,

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.
All this looks pretty good... but...
Outputs are string objects with SQL Statements or just paremeters with
dataconnection key.
This is a pretty bad idea. Your presentation objects should pass data
views, data sets, lists of business objects, etc, to the business layer.
The presentation layer must not know anything about the persistence
mechanism. Otherwise, you end up with expensive code to maintain.

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.
This is a structured programming approach. It is not really my style. I
fail to see how you can truly move business logic through a "God Class." (A
God Class is an antipattern. The God Class sees everything, knows
everything, and does everything. :-). This nearly always violates the
Open-Closed principle and produces fragile code (usually in other layers).
Handing off the difficult part to other layers because it is hard to do it
in the business layer is not my first recommendation.

Note that CRUD functionality is not usually the same as a business rule. In
fact, I would suggest that 90% of the real business rules in your app are
not related at all to CRUD functions. These are database operations.

If your system is truly partitioned this way, then your business logic is in
the presentation layer.
3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.

I read your subsequent posts about why you don't use stored procs. I
understand and sympathize. However, typically in code, we have a Data
Access Layer that hides the fact that your underlying system is a particular
database. This data access layer does many of the connection and CRUD
operations.

If you truly want to reconsider how to partition the functionality of your
system, create an idea in your head of the purpose for each layer. Write
that purpose in large letters on a white board, divided into sections for
each layer, and then break our the activities of your system into methods
that you will implement in each layer. Write these methods under the
heading. Make sure that the purpose matches the method. If the method
doesn't support, defend, and make sense in light of the purpose, move it or
redefine it.

Your answer is your own. It is much easier to work with that way, and if it
works for you, use it. Don't let an author decide for you... or a geek on a
newsgroup :-).

In my experience, I have found that CRUD is a feature of the data access
layer. Business objects enforce business rules and nothing else.
Presentation layers deal with presentation and format validation. That
allows me to seperate the functions in a way that is easier to maintain.

Consider reading about the "Layers" pattern in the Buschmann book on
patterns.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

[Steve Walker]

In message <OX************ **@TK2MSFTNGP10 .phx.gbl>, bradley
<so*****@micros oft.com> writes

"Steve Walker" <st***@otolith. demon.co.uk> wrote in message
news:Iv******* *******@otolith .demon.co.uk...

In message <Xn************ **************@ 127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org > writes

>"bradley" <so*****@micros oft.com> wrote in
>news:#9******* *******@TK2MSFT NGP15.phx.gbl:
>> 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.
Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

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.

Speaking personally, I'm familiar with all of those constructs. The fact
that I can program competently in a language doesn't change my opinion
of whether or not it is horrible. TSQL is horrible. It's BASIC with
support for set-based operations and a slightly uglier procedural
syntax.

I'm not saying it isn't useful. It is immensely so. I'm saying I dislike
it, and were it not an absolute necessity of my professional life, I'd
be happy never to write another line of it.

While I'm being rude about other people's pet languages, by the way, the
same goes for XSLT. And yes, I'm reasonably competent in that too.

--
Steve Walker

[Steve Walker]

In message <Oz************ *@TK2MSFTNGP15. phx.gbl>, Eliyahu Goldin
<re************ *@monarchmed.co m> writes

"Steve Walker" <st***@otolith. demon.co.uk> wrote in message
news:ys******* *******@otolith .demon.co.uk...

In message <#L************ **@TK2MSFTNGP15 .phx.gbl>, Eliyahu Goldin
<re************ *@monarchmed.co m> writes

>"Steve Walker" <st***@otolith. demon.co.uk> wrote in message
>news:Iv******* *******@otolith .demon.co.uk...
>> In message <Xn************ **************@ 127.0.0.1>, Chad Z. Hower aka
>> Kudzu <cp**@hower.org > writes
>> >"bradley" <so*****@micros oft.com> wrote in
>> >news:#9******* *******@TK2MSFT NGP15.phx.gbl:

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

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

>With SQL Server 2005 you can write stored procedures etc. in c#.

Not terribly portable though, is it?

Make your mind. Horrible language vs not terribly portable.

Using C# from within the database is not terribly portable between
databases. Implementing a tiered design with simple stored procedures
gives you more options and allows you to do what SQL is good at in SQL
and what object oriented languages are good at in object orientated
languages. If presentation, domain model, data access and database logic
(i.e. stored procedures)are all distinct tiers it's relatively easy to
substitute a different platform for any one of them. If the stored
procedures are relatively simple CRUD affairs, you will even be able to
migrate to a platform which doesn't support stored procedures with
relative ease.

--
Steve Walker