CODING PRACTICE. Business and Data Access Layers

  • Thread starter Thread starter Savvoulidis Iordanis
  • Start date Start date
S

Savvoulidis Iordanis

Why separate the Data Access Layer (DAL) methods from the Business Layer
(BL)methods of an object ? Why not have them inside the object itself, since
it's going to save its own data, using its own methods?

Is it just a matter of avoiding clutter of the code? Or try to avoid big
objects in memory? Won't the DAL object consume memory by itself anyway?
Any reasonable explanation is appreciated.

TIA
Iordanis
 
its because of the benefits to abstraction. what if the data store
changes, what if the bl layer needs to run on a in-memory model. what if
the underlying database changes? none of these should effect the bl code
unless it has the data access in them.

also for professional developers who write units test, combining the
layers make writing the unit tests more difficult.

-- bruce (sqlwork.com)
 
#1 Business Objects do not have to exist If and Only If there is a database
counter part. Case #1, UnitTests.
#2 Your backend datastore could change, thus layers give you a better way
to maintain your code.

You can look at an example here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
(code is downloadable).

There is a MS "bird's eye view" article I reference. Read and reread that
article several times. Bookmark it, and in a few months, go back and reread
it.
 
Is the 3-tier approach applied in webforms that use webform controls and
datasources such as gridview the sqldatasource controls? Doesn't the
combination of these controls destroy the 3-tier approach? Should I fill the
gridview with data only through code that gets the data from the business
layer, OR by using gridview/sqldatasource properties (the easy way)? I
believe using both methods is inapropriate.
Any comments? How is it done in serious web page development?

TIA
Iordanis
 
Most of those were developed for RAPID development.

In my opinion, RAPID != Good Development.

...
 
Are applications developed without the datasource controls, but only using
code for gridviews etc, any faster? Why do you follow this approach? Isn't
Rapid App Development the Holy Grail of programming? How faster do you work
coding the way you do now?
Any philosophical discussion on that is appreciated (if you can spare any
time on philosophy, that is)

TIA
Iordanis
 
Thanks.
Meanwhile I studied thoroughly MSDN's "Designing Data Tier Components and
Passing Data Through Tiers" practices. It says, that we can pass a custom
business object (ORDERS) created in the DAL (eg. after calling a stored
procedure), back into the business layer. If that custom object has detail
data (ORDER_DETAILS is the details object), we can have a private Dataset
object to represent it. Then it shows how to DataBind the ORDER_DETAILS
dataset to a datagrid. OK so far.

But the example only shows how to set the values of separate textbox
controls on a page based on the values of the property values of the main
custom object (ORDERS). What if What if I want to Databind the main custom
object (ORDERS) to a datagrid as well? The only thing I have is the custom
object's properties. What kind of object should the business Layer return
when the presentation layer calls BOL.GetOrder(x) function? A Dataset, or an
ORDER custom object? Can custom objects be used as datasources by themselves?
TIA
Iordanis
 
Back
Top