Hi Davy
Are you saying the following is bad code?
Aren't I binding to the output of the ORM rather than the data directly?
What would you advise ?
I am using winforms and Entity Framework
List<spCustomerSelect_Result> custs = context.spCustomerSelect("where c.type
= 1 ").ToList();
gridview.DataSource = custs;
Thanks
Kirsten
_____
From: [email protected] [mailto:[email protected]]
On Behalf Of [email protected]
Sent: Saturday, 23 July 2011 9:54 PM
To: ozDotNet
Subject: Re: System.Data classes and List<T>
It's never been a good idea to bind databases direct to output.
Mvc / mvvm etc are attempts to remove code from behind the events of the
screen. The idea being that you can use different views with the same
presenter / controller. It's fun to code, pain in the arse to debug. But
does allow you to unit test it.
I like mvc, mvvm I'm not so hot about.
02c. Davy
"When all you have is a hammer, every problem looks like a nail." I feel
much the same way about xml
_____
From: "Kirsten Greed" <[email protected]>
Sender: [email protected]
Date: Sat, 23 Jul 2011 21:23:05 +1000
To: 'ozDotNet'<[email protected]>
ReplyTo: ozDotNet <[email protected]>
Subject: RE: System.Data classes and List<T>
I am wondering if these days the done thing is not to bind the output of an
ORM directly to the controls in the UI, but rather to have an intermediary
part of the UI between the ORM output and the controls
Is this what model view presenter / model view controller / model view view
controller are about? MVP/MVC/MVVC ?
Kirsten
_____
From: [email protected] [mailto:[email protected]]
On Behalf Of Greg Keogh
Sent: Thursday, 21 July 2011 10:24 AM
To: [email protected]; 'ozDotNet'
Subject: RE: System.Data classes and List<T>
Chaps, your comments are interesting and perhaps make me feel not so guilty
for using System.Data classes in these modern times.
I've only used netTiers and EF4 in recent years, but deep down they all run
a SELECT statement, loop through the rows and move the columns into
collections of objects with matching property names. In the early .NET years
I wrote my own code to do that, and I know VB6 developers who are still
doing it.
The classes and collections returned by netTiers implemented all of the
interfaces I like in System.Data. The EF4 equivalents do not seem to. So
where does that leave me? I fall back to the "convenience" of System.Data
and I feel guilty, but perhaps I shouldn't. Maybe no one is game to admit
that EF4 is a bit immature.
I've had no reply from the EF4 MSDN forum yet.
I will continue to send DataSets to pick lists and grids in my UI. However,
I do perform updates and deletes using the EF4 entities and context, and I'm
reasonably happy with the way it works. It's tedious to eager load an entity
with non-tracking, send it up to the UI, edit or delete it, then attach it
back to the context and call ApplyCurrentValues on all the entities before
saving it.
netTiers is not regarded as a big player in the ORM field, but my experience
so far is that netTiers is generally better than EF4 because its entity
classes and collections are completely self-tracking, and most importantly,
there is no concept of a context. The only reason I'm learning EF4 and using
it is because it's "the latest greatest thing". I guess marketing does work!
Greg
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 6311 (20110720)__________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
