Re: App Architecture: Typed Datasets, EntLib, Performance

Tech-Archive recommends: Speed Up your PC by fixing your registry


See
http://sholliday.spaces.live.com/
In my 5/24/2006 blog entry, I reference this MS article
And a reference to read from start to finish, aka, very informative for a
bird's eye view:
*
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

Deploying Business Entities
find that heading in the MS article.
Read the 3 points, several times each. It takes a few reads to have it sink
in.

Then I'd get the code from my blog, the 5/24/2006 article.
I've matched the MS article , and have typed datasets as the common library
living outside of the tiers.


The enterprise blocks are barely going to affect performance.
The only place they hurt , just a tad bit, is using reflection to
instantiate the concrete classes.
However, reflection compared to the overhead of db communication, is about 3
drops in a gallon of water.


Cowboy is right on, performance is not the be all end all.
You can get great performance with application blocks.


You might read this article also:
http://www.codeproject.com/gen/design/DudeWheresMyBusinessLogic.asp


Finally: The MS article talks about the pros/cons of (typed) datasets vs
custom objects (business entities).
I choose custom objects most of the time.
For reports, I use strong typed datasets.

That's my rule of thumb.






"Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@xxxxxxxxxxxxxxxxxx> wrote in
message news:uCylOiz1GHA.1548@xxxxxxxxxxxxxxxxxxxxxxx
Before getting too deep into this, I have one comment. DO NOT code for
performance alone.

You can write an application that blows the socks off others if you move
as
much of your application to C code and put a service layer on top for the
.NET bits. In the process, you sacrifice maintainability and extensibility
and possibility scalability as well. But, damn, it performs.

To your question, efficiency is not the only thing you should be concerned
with. It is possible you will save a few cycles using untyped DataSets on
the back end. I am not convinced this is the case, but it is certainly
possible. In the process, however, you opt for two disparate systems with
different sets of rules. This leads to a team that is split and where you
cannot easily move people around from middle tier to back end. If this is
how your organization is set up, it is not an issue.

To your questions (INLINE)

"Karch" <nospam@xxxxxxxxxxxxxx> wrote in message
news:eMkPW$y1GHA.1256@xxxxxxxxxxxxxxxxxxxxxxx
I have a web application that I have partitioned into 4 assemblies: web
application (presentation), business entities (typed datasets), business
objects (business logic), and data access (using DAAB). The two areas
that
where I have read conflicting information are the use of typed datasets
and
data access using the Enterprise Library.

Typed datasets:

There seems to be agreement that the use of typed datasets is "good".
However, there is some disagreement about _where_ they should be filled
and used. Some say that they should not be filled by the data access
layer, but rather should exist only in the business layer, which would
merge the untyped dataset returned from the data layer and pass the
typed
dataset to the the web application.

1. Is it more efficient to use untyped datasets in the data access layer
and merge the results into a typed dataset at the business layer level?

Not sure.

2. What are the recommendations or guidelines for using typed datasets
in
this type of architecture?

I would recommend choosing your architecture, objects or datasets, up
front
and sticking with the same archtiecture throughout. If you find that you
need more cycles due to a perf problem, you can then adjust the
application
to try other options like the one you suggest.

Overall, I am more fond of true business objects, but I use code
generators
to avoid having to type a lot (lazy programmers rule ;->). I am currently
using CodeSmith with .NET Tiers, but I actually prefer LLBLGen Pro, as it
is
much easier to define complex relationships. Both create objects that
perform nicely.

A word of caution: If you go with a O/R Mapping layer, as I have, be
careful
as there are some really crappy open source implementations out there
(there
are some good ones, but I ran through quite a few before deciding I was
not
realy "getting something for free" and purchased a commercial O/R Mapper).
As an example, because it is on the top of my head, there is a project
caled
Typed Data Objects that does not use the same name for its dyanmic
parameters. The negative here is you cannot reuse query plans. I am sure
some of the other projects out there suffer from similar issues, so do
research if you go the O/R route.

Data access:

I see the value in using DAAB if I want to be completely provider
agnostic, but what if I know that I will always be using SQL Server?

1. Am I better off in this case, from a performance perspective, to just
use data adapters and sqlclient?

The DAAB (and Enterprise Library) offer more than simple data access. For
example, you have someone else responsible for the data layer code, which
is
a nice thing. Less for you to maintain.

It does add a bit of weight, but I am not sure it is significant enough to
make a decision on the weight alone. I would aim for the EntLib instead of
just the DAAB, as you get some other bits and it is a better model than
the
DAAB model.

Sticking with standard, however? Sure, if you have the need of rolling
your
own data layer, it is an option.

2. Am I just buying myself fewer lines of code at the expense of
performance by using DAAB?

Possibly, but I would state that you should not focus solely on
performance,
unless you have or foresee a performance problem. Too many people are
focused solely on performance and forget other aspects. Using a third
party
library (like EntLib or DAAB) saves you time to focus on other things. If
you find out, during modeling, that you have a perf problem, you can
switch
out to a layer that mimics the routines of the DAAB but is lighter in perf
weight. In fact, if you completely abstract your data access layer, you
can
switch to whatever you want.

I do not, however, think the DAAB is going to be the biggest issue in your
list of potential perf issues.

3. In cases where I expect only one row from a stored procedure, should
I
be using out parameters in my stored procedure and assigning the values
to
a dataset or should I just fill the dataset with a recordset?

If you are getting back a single value, out parameters might gain you
something. If you are grabbing a full row, I am not sure you are going to
buy anything for the complexity you are adding.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside of the box!
*************************************************




.

Relevant Pages

  • Re: App Architecture: Typed Datasets, EntLib, Performance
    ... much of your application to C code and put a service layer on top for the ... application, business entities (typed datasets), business ... and data access. ... I see the value in using DAAB if I want to be completely provider ...
    (microsoft.public.dotnet.framework.aspnet)
  • Typed datasets 3-tier application
    ... We have elected to go with a 3-tier (data, business, ... presentation) model using typed datasets as the data layer. ... Straight vs2005 generated typed datasets for all updatable data access. ... All data access must go through the biz layer, ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Typed datasets 3-tier application
    ... We have elected to go with a 3-tier (data, business, ... presentation) model using typed datasets as the data layer. ... Straight vs2005 generated typed datasets for all updatable data access. ... All data access must go through the biz layer, ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: project references when building N-tier apps
    ... Extract business objects such as User into a third assembly ... which you then reference from both> Business.dll and DataAccess.dll. ... to call the data access layer and provide the above mentioned user.Save ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Classes, collections and data
    ... Being that it is a small app, putting the data access and business logic ... Normally I create a Business Layer that handles logic, calculations, ...
    (microsoft.public.dotnet.languages.vb)