Salakhetdinov Shamil
mcp2004 at mail.ru
Mon Apr 27 04:50:15 CDT 2009
Hi Michael, Thank you for your feedback. In my opinion we're looking for the ways to avoid using custom tools as .netTiers, CSLA.NET, own custom frameworks (I have got developed one like .netTiers, maybe with not that much features but rather similar AFAIS - my own also works pretty well in real life apps) - the main current "killer" framework to try is MS ADO.NET Entity Framework, which is supported by .NET Framework SP1 (VS2008 SP1), but which have some limitations e.g. absense of flexible SPs mapping features (which BTW is not looking as an issue at all to Gustav :) maybe for me only in our SCRUM team) but all(?) that limitations are planned to be fixed in VS2010... Thank you. -- Shamil -----Original Message----- From: "Michael Maddison" <michael at ddisolutions.com.au> To: "Discussion concerning Visual Basic and related programming issues."<dba-vb at databaseadvisors.com> Date: Mon, 27 Apr 2009 17:27:32 +1000 Subject: Re: [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 > > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com >