CODING PRACTICE. Business and Data Access Layers

[=?Utf-8?B?U2F2dm91bGlkaXMgSW9yZGFuaXM=?=]

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

[bruce barker]

Re: CODING PRACTICE. Business and Data Access Layers

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)

Savvoulidis Iordanis wrote:

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
>

[sloan]

Re: CODING PRACTICE. Business and Data Access Layers

#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.space s.live.com/Blog/cns!A68482B9628 A842A!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.






"Savvoulidi s Iordanis" <SavvoulidisIor danis@discussio ns.microsoft.co mwrote
in message news:79E1649C-CAA8-4A32-9486-76342F2A1605@mi crosoft.com...

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
>

[=?Utf-8?B?U2F2dm91bGlkaXMgSW9yZGFuaXM=?=]

Re: CODING PRACTICE. Business and Data Access Layers

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

[Mark Rae [MVP]]

Re: CODING PRACTICE. Business and Data Access Layers

"Savvoulidi s Iordanis" <SavvoulidisIor danis@discussio ns.microsoft.co mwrote
in message news:55D1574C-DE71-4381-BD79-0A6D15F4B83F@mi crosoft.com...

How is it done in serious web page development?

Depends on your definition of "serious", I suppose...

Personally, I do everything in code and never go anywhere near things like
SqlDataSource, Validation controls, Design view etc...


--
Mark Rae
ASP.NET MVP

http://www.markrae.net

[sloan]

Re: CODING PRACTICE. Business and Data Access Layers


Most of those were developed for RAPID development.

In my opinion, RAPID != Good Development.

...



"Savvoulidi s Iordanis" <SavvoulidisIor danis@discussio ns.microsoft.co mwrote
in message news:55D1574C-DE71-4381-BD79-0A6D15F4B83F@mi crosoft.com...

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

[=?Utf-8?B?U2F2dm91bGlkaXMgSW9yZGFuaXM=?=]

Re: CODING PRACTICE. Business and Data Access Layers

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

[Mark Rae [MVP]]

Re: CODING PRACTICE. Business and Data Access Layers

"Savvoulidi s Iordanis" <SavvoulidisIor danis@discussio ns.microsoft.co mwrote
in message news:91424F2A-F432-431F-AC48-F814BA5B5C7F@mi crosoft.com...

Are applications developed without the datasource controls, but only using
code for gridviews etc, any faster?

No idea...

Why do you follow this approach?

For much greater control over what I'm doing...

Isn't Rapid App Development the Holy Grail of programming?

Absolutely not!!! Rapid application development DOES NOT necessarily mean
good application development. Have you ever seen Microsoft FrontPage...?

How faster do you work coding the way you do now?

Much faster.


--
Mark Rae
ASP.NET MVP

http://www.markrae.net