Design Issue

[Matthias S.]

Hi there,

I'm wondering how the "best-practise" of seperating code into a DAL, BLL
and user interface go along with the point and click website creation
through data-binding in VS2003.

If I databind the gridcontrol on my page against a dataview where does
the business logic go? Should the logic operate on the dataview
retrieved from the database? Where does the object model with my beloved
CCustomer, COrder and CAccount-classes go?

If anybody could shed some light how real world applications are
designed these days...

Kind regards,

Matthias

[Manohar Kamath]

Matthais,

There are n ways to skin a cat -- and the same goes with best practices. You
could bind a business object to a grid, or just separate the object from its
view and bind the view (as in MVC pattern). VS.NET will do whatever you tell
it to, and if you designed your app well, you can still apply the best
practices with the tool..

here's some good reading on the topic:

http://msdn.microsoft.com/library/de...MSpatterns.asp

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Matthias S." <postamt@_remove_emvoid_remove_.de> wrote in message
news:OS**************@TK2MSFTNGP15.phx.gbl...

Hi there,

I'm wondering how the "best-practise" of seperating code into a DAL, BLL
and user interface go along with the point and click website creation
through data-binding in VS2003.

If I databind the gridcontrol on my page against a dataview where does
the business logic go? Should the logic operate on the dataview
retrieved from the database? Where does the object model with my beloved
CCustomer, COrder and CAccount-classes go?

If anybody could shed some light how real world applications are
designed these days...

Kind regards,

Matthias

[Matthias S.]

Hi Manohar,

thanks for the link! That'll keep me busy for the rest of the night ;)

Again, thanks!

Matthias

Manohar Kamath wrote:

Matthais,

There are n ways to skin a cat -- and the same goes with best practices. You
could bind a business object to a grid, or just separate the object from its
view and bind the view (as in MVC pattern). VS.NET will do whatever you tell
it to, and if you designed your app well, you can still apply the best
practices with the tool..

here's some good reading on the topic:

http://msdn.microsoft.com/library/de...MSpatterns.asp

[Kevin Spencer]

Good questions, Matthias.

Bacially, you have to think of each layer as representing ONLY what that
layer represents. The data layer should have methods that return data
objects only, such as DataReaders, DataTables, and DataSets. That is the
only functionality it should serve. Any Business logic or UI logic should
not be in there. The business layer should process the data and make it
"pallatable" to the UI. the business layer should contain no UI-related
code, such as formatting, UI controls, etc. It should create nice packages
of data, and perform all the work with it. The presentation layer should
only contain UI logic. It should process no data whatsoever. It should
present it to the user, take input from the user, and hand the input and
data back to the business layer for processing.

Thus, the presentation layer requests business data from the business layer,
which in turn, talks to the data layer, processes the data, and hands it to
the presentation layer. When user input is received by the presentation
layer, it should hand the user input to the business layer, which then
processes the user input and data, and, if necessary, hands it all back to
the data layer.

Does that help?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
"Matthias S." <postamt@_remove_emvoid_remove_.de> wrote in message
news:OS**************@TK2MSFTNGP15.phx.gbl...

Hi there,

I'm wondering how the "best-practise" of seperating code into a DAL, BLL
and user interface go along with the point and click website creation
through data-binding in VS2003.

If I databind the gridcontrol on my page against a dataview where does the
business logic go? Should the logic operate on the dataview retrieved from
the database? Where does the object model with my beloved CCustomer,
COrder and CAccount-classes go?

If anybody could shed some light how real world applications are designed
these days...

Kind regards,

Matthias

[Matthias S.]

Hi Kevin,

thanks for your reply. What you are writing describes the way I kept
thinking about 3 tier solutions until I recently received my copy of
Visual Studio 2003. Then I started wondering, why putting a DataGrid
directly onto a page and it's not only recommended, but is advertised at
every possible corner.

If I stick to a solid architecture based on this model, I'd never
possibly encounter a situation where I would need to put a GridControl
onto my page wich is directly bound to a table in my db.

I'm not in for a rant here about the VS. It's no doubt a great tool.
Just wondering if I missed something out...

Matthias

Kevin Spencer wrote:

Good questions, Matthias.

Bacially, you have to think of each layer as representing ONLY what that
layer represents. The data layer should have methods that return data
objects only, such as DataReaders, DataTables, and DataSets. That is the
only functionality it should serve. Any Business logic or UI logic should
not be in there. The business layer should process the data and make it
"pallatable" to the UI. the business layer should contain no UI-related
code, such as formatting, UI controls, etc. It should create nice packages
of data, and perform all the work with it. The presentation layer should
only contain UI logic. It should process no data whatsoever. It should
present it to the user, take input from the user, and hand the input and
data back to the business layer for processing.

Thus, the presentation layer requests business data from the business layer,
which in turn, talks to the data layer, processes the data, and hands it to
the presentation layer. When user input is received by the presentation
layer, it should hand the user input to the business layer, which then
processes the user input and data, and, if necessary, hands it all back to
the data layer.

Does that help?

[Kevin Spencer]

Hi Matthias,

Sample code is not meant to be copied and used as is. It exists solely for
the purpose of illustrating a certain functionality, method, property,
whatever. Samples in the .Net SDK should not be taken as recommendatins
regarding good architecture and design. Remember that part of the purpose of
the SDK is to help ASP developers to migrate. Microsoft has plenty of
articles that deal specifically with architecture and design issues. And
you'll see that those articles are along the same lines as what I wrote.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Matthias S." <postamt@_remove_emvoid_remove_.de> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

Hi Kevin,

thanks for your reply. What you are writing describes the way I kept
thinking about 3 tier solutions until I recently received my copy of
Visual Studio 2003. Then I started wondering, why putting a DataGrid
directly onto a page and it's not only recommended, but is advertised at
every possible corner.

If I stick to a solid architecture based on this model, I'd never possibly
encounter a situation where I would need to put a GridControl onto my page
wich is directly bound to a table in my db.

I'm not in for a rant here about the VS. It's no doubt a great tool. Just
wondering if I missed something out...

Matthias

Kevin Spencer wrote:

Good questions, Matthias.

Bacially, you have to think of each layer as representing ONLY what that
layer represents. The data layer should have methods that return data
objects only, such as DataReaders, DataTables, and DataSets. That is the
only functionality it should serve. Any Business logic or UI logic should
not be in there. The business layer should process the data and make it
"pallatable" to the UI. the business layer should contain no UI-related
code, such as formatting, UI controls, etc. It should create nice
packages of data, and perform all the work with it. The presentation
layer should only contain UI logic. It should process no data whatsoever.
It should present it to the user, take input from the user, and hand the
input and data back to the business layer for processing.

Thus, the presentation layer requests business data from the business
layer, which in turn, talks to the data layer, processes the data, and
hands it to the presentation layer. When user input is received by the
presentation layer, it should hand the user input to the business layer,
which then processes the user input and data, and, if necessary, hands it
all back to the data layer.

Does that help?