SW Architecture: OOP in Mulit-Tier-Applications good practice anymore ?

[Gordon]

Hi,
we are at the point to start a new big SW Project.

As probably many of you, we design our Applications in an Multi-Tier
approach,
where the UI as Thin Client (IE) accesses the Backend asynchronsously via
WebServices using XML Data.

Now my question:
Makes it sense anymore in this multi-tier environment, collecting first the
Data from the
SQL Server into a DataSet, then storing it into Business Objects and then
building out
of this BO´s the XML to send it to the UI ?

Should we not purge the BO´s to write directly from the DataSets to XML and
vica versa ?
Saves a lot of design and implemtation time ! ;-)

Does anyone discussed already this Design approach or have good arguments
to stay with the old OOP paradigma ?

thx.

gordon

 

[Nicholas Paldino [.NET/C# MVP]]

Gordon,

The approach I have been taking lately is to use strongly-typed data
sets, and pass them through my layers, from UI, to business, to data. The
business layer will just take a data set, and do whatever it needs to do,
then forward that to the data layer, where it will be persisted. Since the
data set derives from DataSet, it's easy enough to make generic.

I am shying away from business objects at the moment, as I can't justify
their stateful nature with the lack of state in the transactions that I want
to do. The DataSet helps to convey all of that information into the
transaction stream and out.

Also, I would not use IE as a front end anymore. There is no reason to
not use Smart Clients which would connect to your data through web requests.
Generating the user interface is just too painful in a browser.

Hope this helps.