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