Re: App Architecture: Typed Datasets, EntLib, Performance
- From: "Cowboy \(Gregory A. Beamer\)" <NoSpamMgbworld@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 13 Sep 2006 08:29:07 -0500
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!
*************************************************
.
- Follow-Ups:
- References:
- Prev by Date: Overhead converting .htm files to .aspx
- Next by Date: Re: Datagrid - HyperlinkColumn and variables
- Previous by thread: App Architecture: Typed Datasets, EntLib, Performance
- Next by thread: Re: App Architecture: Typed Datasets, EntLib, Performance
- Index(es):
Relevant Pages
|
