ms architecture docs vs pet shop

  • Thread starter Thread starter Bruce
  • Start date Start date
B

Bruce

currently making major architecture decisions. msdn docs say 'custom
objects to represent data are too complicated... use datareader' while pet
shop actually uses object representations of data, and this is certainly the
norm in java world, ( at least last week).

can someone help me understand?


thanks very much
 
Where do you want your business logic? In your UI, in a business layer or in
a data layer? I think it's safe to discard the first option, leaving you
with the choice of writing business rules in some SQL dialect designed to
basically perform set operations, or writing them in a powerful, modern
programming language.

Colin
 
agreed. I'm talking about business entity objects as opposed to business
logic. ms pet shop has such entity objects as a layer over the data, but the
docs suggest to avoid these 'custom data objects' as being too complex, and
go straight to ado objects.
 
Well, MS says a lot in terms of architecture, and their implementations are
always of a qulity that makes me think someone needs to get an architect
into their teams :-)

After all, they STILL work with handwritten DAL's, wehere a generic one
would achieve the same.

I am a hugh advocate of real business objects, alebit making them right is a
LOT moer work than MS has put into their samples and than MS puts into
ObjectSpaces.

"custom data objects" maybe complex. Custom business objects are easier to
use and use less code than ADO objects, when you use a sane framework for
this. They just speed up everything. Including data access, thanks fo the
dataset not really being efficient.

--
Regards

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
 
Sorry. I was in a bit of a hurry when I wrote the response. I use custom
data access objects, but I'll use a generator to create them. LLBLGen is a
good one, and you can get the same results with CodeSmith. Using a code
generator takes care of all the hard work and avoids needing to include
implementation details in the business logic layers.

I see a lot of people promoting generic data layers with functions like
"ExecuteProcedure" and "ExecuteSQL." If you're going to do that you might as
well just use the ADO.Net functionality that's provided for you.

Colin
 
Yes, but then there is also the wy to use an O/R mapper and go all the way
and just work with objects.

Without writing any manual code for just having the objects, you know.

I always found a semi-data-layer like LLBGEN or Codesmith too limiting.

--
Regards

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
 
Back
Top