[dba-VB] ADO.NET Entity Framework - to use or not?

Don't mean to intrude, but are you looking for something like
http://www.nettiers.com ?
We've used it in several projects, but not the one we are working on
now.
It works pretty damn well IMO. 

Cheers

Michael M


-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Monday, 27 April 2009 2:31 AM
To: Salakhetdinov Shamil; Discussion concerning Visual Basic and related
programming issues.
Subject: Re: [dba-VB] ADO.NET Entity Framework - to use or not?

As far as I know, there are two distinct meaninings of the acronym PITA.
One
is Pain in the Ass and the other is Point In Time Archicture. I was
involved
in one significant project which used the latter meaning, and several
dozen
which used the former.

On the subject of ORM, I suggest that you contact Paul Nielson, who is a
SQL
MVP and author of the SQL Bible books, and who has written an ORM thing
for
SQL Server. My basic take on this is at the low end there will be four
procedures for each table (Select, Update, Delete, and Insert). These
are
quite easy to generate. The trick is in how to handle objects --
consider
the classic Orders+OrderDetails example, just to keep the discussion
simple.
In the relational world you treat Orders and OrderDetails as separate
things
-- first you add the Order, then you add one or more Details to said
Order.
This can grow rapidly more complicated given the existence of
DetailTypes
(Been there, done that). I'll let you run free with the concept of
Detail
Types, but suffice to say that they have a few columns in common and
many
unique to the particular type. (For example, Car Rental vs. Hotel Room
Booking vs. Seat in a U2 concert.)

Suppose that you want to handle this aggregation as an object. What do
you
gain by doing so?

In another app I once worked on, users could define the attributes of
various objects they dealt with. They could add a potentially unlimited
number of attributes to these objects, which in this case were pulp and
paper rolls. Various clients were interested in these or those
attributes,
and we modeled this as rows in a table. IOW, one virtual row actually
expanded to N rows in a child table, and these were all grabbed and
assembled into one row, kind of like a crosstab thing.

It sucked. I spent a lot of time enhancing the performance and chopped
it by
ten, but it still sucked. It took upwards of 10 seconds to retrieve a
given
object. The speedy solution was to include all columns in the
OrderDetails
table and then restrict the view to the particular columns of interest
to
the particular client. This worked well in terms of performance but
meant
that our developers had to recreate various views for each client.

A.

On Sun, Apr 26, 2009 at 5:28 AM, Salakhetdinov Shamil
<mcp2004 at mail.ru>wrote:

> Hi Gustav,
>
> Clarification to the subject title -- I meant -- "to use or not to use
now
> for real life applications development" -- for sure -- use in our
ongoing
> Northwind.NET project, in one of the future releases.
>
> Thank you.
>
> --
> Shamil
>
> -----Original Message-----
> From: "Gustav Brock" <Gustav at cactus.dk>
> To: <dba-vb at databaseadvisors.com>
> Date: Sat, 25 Apr 2009 23:07:38 +0200
> Subject: Re: [dba-VB] ADO.NET Entity Framework - to use or not?
>
> > Hi Shamil
> >
> > There probably isn't a definitive recommendation - as always, it
depends
> - but I must say I find it quite fascinating to "leave" the tables and
views
> and work with objects instead.
>
> <snip>
> _______________________________________________
> dba-VB mailing list
> dba-VB at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-vb
> http://www.databaseadvisors.com
>
>
_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
http://www.databaseadvisors.com