ASP.Net Mid Tier Component Design

[gabe]

I have a general design question.

What's a 'Best Practice' for middle tier component design?

I'm thinking of a web form that contains data from multiple tables. The
data is supplied from one or more muti-table joins. Is it better to
populate a form by binding to dataset tables or load the data in
collection classes? How are the updates handled? Would there be a
stored procedure for each table that is updated, and have all the
updates wrapped in a transaction?

I know it's a pretty open question. Does someone have a good component
design book recomendation or is some of this available with Microsoft
application blocks?

Thanks in advance,

Gabe

[Steve C. Orr [MVP, MCSD]]

There's no best answer to these questions without first knowing a whole lot
about your requirements. Since most of us don't have that kind of time,
it's up to you to decide ultimately. If you want to make an informed
decision, I suggest you read the following book:

Expert One-on-One Visual Basic .NET Business Objects (by Rockford Lhotka)
http://www.amazon.com/exec/obidos/AS...&link_code=as1

or here's the C# version if you prefer:
http://www.amazon.com/exec/obidos/AS...&link_code=as1

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net

"gabe" <ga*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

I have a general design question.

What's a 'Best Practice' for middle tier component design?

I'm thinking of a web form that contains data from multiple tables. The
data is supplied from one or more muti-table joins. Is it better to
populate a form by binding to dataset tables or load the data in
collection classes? How are the updates handled? Would there be a
stored procedure for each table that is updated, and have all the
updates wrapped in a transaction?

I know it's a pretty open question. Does someone have a good component
design book recomendation or is some of this available with Microsoft
application blocks?

Thanks in advance,

Gabe

[Joshua Mitts]

Try this, it's a whole catalog of free "patterns & practices" guides:

http://msdn.microsoft.com/practices/...t/default.aspx

--

Joshua Mitts
jo****@msn.com

"gabe" <ga*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

I have a general design question.

What's a 'Best Practice' for middle tier component design?

I'm thinking of a web form that contains data from multiple tables. The
data is supplied from one or more muti-table joins. Is it better to
populate a form by binding to dataset tables or load the data in
collection classes? How are the updates handled? Would there be a
stored procedure for each table that is updated, and have all the
updates wrapped in a transaction?

I know it's a pretty open question. Does someone have a good component
design book recomendation or is some of this available with Microsoft
application blocks?

Thanks in advance,

Gabe

[Kevin Spencer]

Hi Gabe,

It's better not to think in terms of iter *position* but of tier
*functionality*. In other words, the phrase "middle tier" in itself lends to
your confusion. Let me use your question as an example:

I'm thinking of a web form that contains data from multiple tables. The
data is supplied from one or more muti-table joins. Is it better to
populate a form by binding to dataset tables or load the data in
collection classes? How are the updates handled? Would there be a
stored procedure for each table that is updated, and have all the
updates wrapped in a transaction?
Okay, the first thing you mention is a WebForm. That is the presentation
tier. So, we are talking only about the presentation level when we talk
about any kind of user interface.

Second, you mention that the WebForm "contains" data. Incorrect. A user
interface element *presents* data. Although this difference in terminology
may seem purely semantic, it helps to separate the various tiers in your
mind. Yes, in a sense, it contains data, but in a more important sense, it
presents data. That is, the purpose of the presentation tier is to display
data. It is not a storage mechanism. Even though it has storage
capabilities, these are for its own use.

The only thing that should be spoken of as containing data is the data
source. Everything else is simply a mechanism for transporting that data
back and forth to and from the user to and from the data source, or a
mechanism for munging that data in some form or fashion.

The "binding" terminology is excellent for the relationship of data to the
presentation tier, as it implies that the data is not *contained* in the
presentation tier, but merely *bound* or "linked" to it somehow.

So, what you term the "middle" tier is actually more usefully called the
"business" tier. This is the tier which performs business logic with the
data in your app. It applies the business rules of your app to the data it
works with. In a sense, it is the "business end" of your application; the
place where everything really happens. The presentation tier is more of a
messaging utility, a "universal translator" which speaks human at one end,
and business logic at the other.

Below the business tier is another tier of functionality, which can be
called the "data tier." This is not where data is stored either, but is a
set of utilities for communicating with data stores. It is a "universal
translator" between business objects and data stores.

The data store itself can be thought of as a "tier" as well,, but just as
often is not.

In any case, I hope you can see how thinking of tiers in functional terms is
useful.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

"gabe" <ga*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...I have a general design question.

What's a 'Best Practice' for middle tier component design?

I'm thinking of a web form that contains data from multiple tables. The
data is supplied from one or more muti-table joins. Is it better to
populate a form by binding to dataset tables or load the data in
collection classes? How are the updates handled? Would there be a
stored procedure for each table that is updated, and have all the
updates wrapped in a transaction?

I know it's a pretty open question. Does someone have a good component
design book recomendation or is some of this available with Microsoft
application blocks?

Thanks in advance,

Gabe