Re: System.Data classes and ListT
Yeah, originally I thought the same too, filling a gap, but it I believe with my amateur time with doing WP7 development, this is mainly the canonical way of consuming data for WP7 apps, always makes me wonder why, as it seems heavy over 3G for phones transmitting this verbose bunch of XML data. On Sun, Jul 24, 2011 at 3:16 PM, Greg Keogh g...@mira.net wrote: That's interesting, if it's not good practice to send back entities over WCF, then why is WCF Data Services around? That's a curious question I have. I’m just reporting what my books say. I generally agree with them for large scale apps. Entity Framework 4 In Actionhttp://www.amazon.com/Entity-Framework-Action-Stefano-Mostarda/dp/1935182188 Entity Frameworkhttp://www.amazon.com/Programming-Entity-Framework-Julia-Lerman/dp/059652028X I reckon WCF Data Services are just another one of those so-called RAD hobby toys that Microsoft trotted out to impress people at SIGs. I wouldn’t create a monolithic app with that stuff if you paid me ... well, maybe if you paid me! Greg
RE: System.Data classes and ListT
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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Thursday, 21 July 2011 10:24 AM To: djones...@gmail.com; 'ozDotNet' Subject: RE: System.Data classes and ListT 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
Re: System.Data classes and ListT
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 -Original Message- From: Kirsten Greed kirst...@jobtalk.com.au Sender: ozdotnet-boun...@ozdotnet.com Date: Sat, 23 Jul 2011 21:23:05 To: 'ozDotNet'ozdotnet@ozdotnet.com Reply-To: ozDotNet ozdotnet@ozdotnet.com Subject: RE: System.Data classes and ListT 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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Thursday, 21 July 2011 10:24 AM To: djones...@gmail.com; 'ozDotNet' Subject: RE: System.Data classes and ListT 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
RE: System.Data classes and ListT
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 ListspCustomerSelect_Result custs = context.spCustomerSelect(where c.type = 1 ).ToList(); gridview.DataSource = custs; Thanks Kirsten _ From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of djones...@gmail.com Sent: Saturday, 23 July 2011 9:54 PM To: ozDotNet Subject: Re: System.Data classes and ListT 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 kirst...@jobtalk.com.au Sender: ozdotnet-boun...@ozdotnet.com Date: Sat, 23 Jul 2011 21:23:05 +1000 To: 'ozDotNet'ozdotnet@ozdotnet.com ReplyTo: ozDotNet ozdotnet@ozdotnet.com Subject: RE: System.Data classes and ListT 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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Thursday, 21 July 2011 10:24 AM To: djones...@gmail.com; 'ozDotNet' Subject: RE: System.Data classes and ListT 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
RE: System.Data classes and ListT
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 Both EF4 books I have mention this and hint that binding to entities or passing them over service boundaries is not a good practice. For small apps or maintenance utilities (I'm writing one now), editing entities directly doesn't worry me, but when you start passing them over WCF or Remoting then I'd consider using DTOs (Data Transfer Objects) that are custom views of the entities. However, you then have to write more infrastructure to move them around. Is this what model view presenter / model view controller / model view view controller are about? MVP/MVC/MVVC ? Kirsten Those patterns solve a different problem. Your sample code where you bind the query results to a grid is fine for small apps, but as you scale-up and have tiers, then it's impractical. Nathan, I generally agree with your comments, but you need to write so much more infrastructure. However, I'm still stuck with the limitations of the features implemented by EF4 entities and collections. As a comparison, I looked at some netTiers output classes and I challenge anyone to casually knock-up classes that implements it's interfaces: Generic Collection ListBaseT : BindingListT, IBindingListView, IBindingList, IList, ICloneable, ICloneableEx, IListSource, ITypedList, IDisposable, IComponent, IRaiseItemChangedEvents, IDeserializationCallback Sample Entity FooBase : EntityBase, IMedia, IEntityIdMediaKey, System.IComparable, System.ICloneable, ICloneableEx, IEditableObject, IComponent, INotifyPropertyChanged The System.Data classes implement most of these as well and that's why I find them so convenient. Greg
RE: System.Data classes and ListT
If I go to seek.com.au and type in Nettiers I get no results. Entity Framework gives 97 jobs in Australia Are there features EF has that Nettiers doesn't? _ From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Sunday, 24 July 2011 9:06 AM To: 'ozDotNet' Subject: RE: System.Data classes and ListT 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 Both EF4 books I have mention this and hint that binding to entities or passing them over service boundaries is not a good practice. For small apps or maintenance utilities (I'm writing one now), editing entities directly doesn't worry me, but when you start passing them over WCF or Remoting then I'd consider using DTOs (Data Transfer Objects) that are custom views of the entities. However, you then have to write more infrastructure to move them around. Is this what model view presenter / model view controller / model view view controller are about? MVP/MVC/MVVC ? Kirsten Those patterns solve a different problem. Your sample code where you bind the query results to a grid is fine for small apps, but as you scale-up and have tiers, then it's impractical. Nathan, I generally agree with your comments, but you need to write so much more infrastructure. However, I'm still stuck with the limitations of the features implemented by EF4 entities and collections. As a comparison, I looked at some netTiers output classes and I challenge anyone to casually knock-up classes that implements it's interfaces: Generic Collection ListBaseT : BindingListT, IBindingListView, IBindingList, IList, ICloneable, ICloneableEx, IListSource, ITypedList, IDisposable, IComponent, IRaiseItemChangedEvents, IDeserializationCallback Sample Entity FooBase : EntityBase, IMedia, IEntityIdMediaKey, System.IComparable, System.ICloneable, ICloneableEx, IEditableObject, IComponent, INotifyPropertyChanged The System.Data classes implement most of these as well and that's why I find them so convenient. Greg __ Information from ESET NOD32 Antivirus, version of virus signature database 6317 (20110722) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
RE: System.Data classes and ListT
If I go to seek.com.au and type in Nettiers I get no results. Entity Framework gives 97 jobs in Australia A popularity poll on seek.com.au! I'm surprised that any ad would bother to go down to the level of the ORM they're using, to me they're just inconsequential tools in the bigger picture. Are there features EF has that Nettiers doesn't? Lazy loading, Entity SQL, a nice designer (maybe others, but it's hard to compare). netTiers is just a code-generated DAL with self-tracking entity classes, nothing more, so it rarely gets mentioned and there are lots of competitors for it. Greg
Re: System.Data classes and ListT
That's interesting, if it's not good practice to send back entities over WCF, then why is WCF Data Services around? That's a curious question I have. On Sun, Jul 24, 2011 at 9:06 AM, Greg Keogh g...@mira.net wrote: 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 ** ** Both EF4 books I have mention this and hint that binding to entities or passing them over service boundaries is not a good practice. For small apps or maintenance utilities (I’m writing one now), editing entities directly doesn’t worry me, but when you start passing them over WCF or Remoting then I’d consider using DTOs (Data Transfer Objects) that are custom views of the entities. However, you then have to write more infrastructure to move them around. ** ** Is this what model view presenter / model view controller / model view view controller are about? MVP/MVC/MVVC ? Kirsten ** ** Those patterns solve a different problem. ** ** Your sample code where you bind the query results to a grid is fine for small apps, but as you scale-up and have tiers, then it’s impractical. ** ** Nathan, I generally agree with your comments, but you need to write so much more infrastructure. However, I’m still stuck with the limitations of the features implemented by EF4 entities and collections. As a comparison, I looked at some netTiers output classes and I challenge anyone to casually knock-up classes that implements it’s interfaces: ** ** *Generic Collection* ListBaseT : BindingListT, IBindingListView, IBindingList, IList, ICloneable, ICloneableEx, IListSource, ITypedList, IDisposable, IComponent, IRaiseItemChangedEvents, IDeserializationCallback ** ** *Sample Entity* *FooBase* : EntityBase, IMedia, IEntityIdMediaKey, System.IComparable, System.ICloneable, ICloneableEx, IEditableObject, IComponent, INotifyPropertyChanged ** ** The System.Data classes implement most of these as well and that’s why I find them so convenient. ** ** Greg
RE: System.Data classes and ListT
That's interesting, if it's not good practice to send back entities over WCF, then why is WCF Data Services around? That's a curious question I have. I'm just reporting what my books say. I generally agree with them for large scale apps. Entity Framework 4 In Action http://www.amazon.com/Entity-Framework-Action-Stefano-Mostarda/dp/193518218 8 Entity Framework http://www.amazon.com/Programming-Entity-Framework-Julia-Lerman/dp/05965202 8X I reckon WCF Data Services are just another one of those so-called RAD hobby toys that Microsoft trotted out to impress people at SIGs. I wouldn't create a monolithic app with that stuff if you paid me ... well, maybe if you paid me! Greg
System.Data classes and ListT
Folks, I get the impression that the DataSet and its child classes classes are falling out of favour, is that true? However, I personally find them to be very convenient and full-featured for apps of all sizes (but I don't expose them to the outside world of course and my discussion here is only about private use). What I like about DataView and DataRow are the huge number of interfaces they support, and for me the most important features are these: 1. When bound to a grid you get bi-directional sorting with no code at all. 2. They supports SQL-like filter expressions (Foo Like '%bar%') AND (FooId 666) for example, and applying these filters is blazingly fast. 3. IEditableObject in DataRowView gives begin/end edit semantics. While coding lots of Entity Framework 4 over the last several weeks I often have to materialize a collection of entities and send them up to the UI for display in grids or pickers. The EF4 context only allows materializing T[] arrays or ListT of entities, and these are woeful compared to DataView and DataRow, they don't any of the three lovely features listed above. I have resorted to converting my EF4 query results from raw DbDataRecord back to DataRow so I get all the functionality back. Why do I have to do this workaround? Am I missing some other technique? Note, the entities and collections created by netTiers support all the interfaces that the System.Data classes do, so it's only after migrating to EF4 that I'm hitting this irritation. It seems that I'm taking a step backwards with EF4 entities and hence doing stupid workarounds like converting to System.Data objects. I'm told there is an MSDN EF4 discussion group, so I'll ask about this in there once I find it and get in. Greg
Re: System.Data classes and ListT
Ok, who wants to banish Greg? Bags not. On Wed, Jul 20, 2011 at 3:55 PM, Greg Keogh g...@mira.net wrote: Folks, I get the impression that the DataSet and its child classes classes are falling out of favour, is that true? However, I personally find them to be very convenient and full-featured for apps of all sizes (but I don’t expose them to the outside world of course and my discussion here is only about private use). What I like about DataView and DataRow are the huge number of interfaces they support, and for me the most important features are these: ** ** 1. When bound to a grid you get bi-directional sorting with no code at all. 2. They supports SQL-like filter expressions (Foo Like '%bar%') AND (FooId 666) for example, and applying these filters is blazingly fast. 3. IEditableObject in DataRowView gives begin/end edit semantics. ** ** While coding lots of Entity Framework 4 over the last several weeks I often have to materialize a collection of entities and send them up to the UI for display in grids or pickers. The EF4 context only allows materializing T[] arrays or ListT of entities, and these are woeful compared to DataView and DataRow, they don’t any of the three lovely features listed above. ** ** I have resorted to converting my EF4 query results from raw DbDataRecord back to DataRow so I get all the functionality back. Why do I have to do this workaround? Am I missing some other technique? ** ** Note, the entities and collections created by netTiers support all the interfaces that the System.Data classes do, so it’s only after migrating to EF4 that I’m hitting this irritation. It seems that I’m taking a step backwards with EF4 entities and hence doing stupid workarounds like converting to System.Data objects. ** ** I’m told there is an MSDN EF4 discussion group, so I’ll ask about this in there once I find it and get in. ** ** Greg
Re: System.Data classes and ListT
I think you just answered yourself, keyword is convenience. Isn't that what all these frameworks are for? To make things convenient for us developers. Sure people get bored of technologies pretty quickly, but what ever does the job, and if you know it well and can achieve better results with it, then why not? I wouldn't say they're going away or anything, there just won't be any investments made to enhance it any more as they probably feel it's complete and serves its purpose. Maybe you should start fretting when they deprecate it all, but I don't think they would for now, it is a set of classes that fall under the ADO.NET set. On Wed, Jul 20, 2011 at 5:55 PM, Greg Keogh g...@mira.net wrote: Folks, I get the impression that the DataSet and its child classes classes are falling out of favour, is that true? However, I personally find them to be very convenient and full-featured for apps of all sizes (but I don’t expose them to the outside world of course and my discussion here is only about private use). What I like about DataView and DataRow are the huge number of interfaces they support, and for me the most important features are these: ** ** 1. When bound to a grid you get bi-directional sorting with no code at all. 2. They supports SQL-like filter expressions (Foo Like '%bar%') AND (FooId 666) for example, and applying these filters is blazingly fast. 3. IEditableObject in DataRowView gives begin/end edit semantics. ** ** While coding lots of Entity Framework 4 over the last several weeks I often have to materialize a collection of entities and send them up to the UI for display in grids or pickers. The EF4 context only allows materializing T[] arrays or ListT of entities, and these are woeful compared to DataView and DataRow, they don’t any of the three lovely features listed above. ** ** I have resorted to converting my EF4 query results from raw DbDataRecord back to DataRow so I get all the functionality back. Why do I have to do this workaround? Am I missing some other technique? ** ** Note, the entities and collections created by netTiers support all the interfaces that the System.Data classes do, so it’s only after migrating to EF4 that I’m hitting this irritation. It seems that I’m taking a step backwards with EF4 entities and hence doing stupid workarounds like converting to System.Data objects. ** ** I’m told there is an MSDN EF4 discussion group, so I’ll ask about this in there once I find it and get in. ** ** Greg
Re: System.Data classes and ListT
Hi Greg.. I've worked a bit with an open source app called nSurvey ( http://survey.codeplex.com), and it uses the datatables and datasets all the way from DB to UI. However, it's overridden/extended the dataset and data table to make them more like strongly bound types. I don't know if these are auto generated (netTiers or other) data objects, but there are examples in the Branch ++ survey-1.2.3.1 ++ Reflector ++ NSurvey BE ++ Votations.NSurvey.Data project section, and there are examples in the Web App Project (ie. Branch ++ survey-1.2.3.1 ++ Survey WAP ++ NSurveyAdmin ++ UserControls ), files which show how the data is extracted and added to the data objects. The DAL uses the old MS Data Application Block helpers to massage the data to and from the db. As with all models, there's pros and cons, some of which I really noticed were PRO - single data object to get data from db to UI in a *relatively* strongly typed manner CONS - a real b!tch to hand code new Data object classes.. CONS - the data objects seemed heavy to use, ie. lots of typing. I personally like using the ListT for transporting entities.. A fairly simple linq query can be used to sort and/or query the list, and if you're using .Net 4.0, then the TPL extension of .AsParallel may add some zip to the sort process. Grant On Wed, Jul 20, 2011 at 5:55 PM, Greg Keogh g...@mira.net wrote: Folks, I get the impression that the DataSet and its child classes classes are falling out of favour, is that true? However, I personally find them to be very convenient and full-featured for apps of all sizes (but I don’t expose them to the outside world of course and my discussion here is only about private use). What I like about DataView and DataRow are the huge number of interfaces they support, and for me the most important features are these: ** ** 1. When bound to a grid you get bi-directional sorting with no code at all. 2. They supports SQL-like filter expressions (Foo Like '%bar%') AND (FooId 666) for example, and applying these filters is blazingly fast. 3. IEditableObject in DataRowView gives begin/end edit semantics. ** ** While coding lots of Entity Framework 4 over the last several weeks I often have to materialize a collection of entities and send them up to the UI for display in grids or pickers. The EF4 context only allows materializing T[] arrays or ListT of entities, and these are woeful compared to DataView and DataRow, they don’t any of the three lovely features listed above. ** ** I have resorted to converting my EF4 query results from raw DbDataRecord back to DataRow so I get all the functionality back. Why do I have to do this workaround? Am I missing some other technique? ** ** Note, the entities and collections created by netTiers support all the interfaces that the System.Data classes do, so it’s only after migrating to EF4 that I’m hitting this irritation. It seems that I’m taking a step backwards with EF4 entities and hence doing stupid workarounds like converting to System.Data objects. ** ** I’m told there is an MSDN EF4 discussion group, so I’ll ask about this in there once I find it and get in. ** ** Greg
Re: System.Data classes and ListT
Hi, At the moment, at work, there are three projects running and the one that I support. Legacy app. Uses datasets everywhere. Pros. Very fast, readonly application. Cons. Impossible to debug / modify, data is often loaded behind the scenes which cause temporary database table locks .Net 4 with EF Pros. Developpers very engaged with the project, lots of sexy tech. Cons It's been in development now for 6 months and very little visible progress has been made. One screen is done with what ammonts to a single select * .Net 3.5. Nhibernate Pros Works very well, transparent for ui developpers. Cons Misconceptions with heriacical classes in nhibernate has made it impossible to modify the data source. we have hundreds of work arounds to solve the inheritance problems. .Net 3.5 using datasets mapped to objects. Pros. Very easy to use, easy to maintain and add functionality. Cons. The code base is easily twice as big as the other projects Personally, if I was doing a new website. I would use nhibernate Web interface for existing database, ef. Stand alone Application, ado datasets and map to objects. Davy. When all you have is a hammer, every problem looks like a nail. I feel much the same way about xml -Original Message- From: Greg Keogh g...@mira.net Sender: ozdotnet-boun...@ozdotnet.com Date: Wed, 20 Jul 2011 17:55:23 To: 'ozDotNet'ozdotnet@ozdotnet.com Reply-To: ozDotNet ozdotnet@ozdotnet.com Subject: System.Data classes and ListT Folks, I get the impression that the DataSet and its child classes classes are falling out of favour, is that true? However, I personally find them to be very convenient and full-featured for apps of all sizes (but I don't expose them to the outside world of course and my discussion here is only about private use). What I like about DataView and DataRow are the huge number of interfaces they support, and for me the most important features are these: 1. When bound to a grid you get bi-directional sorting with no code at all. 2. They supports SQL-like filter expressions (Foo Like '%bar%') AND (FooId 666) for example, and applying these filters is blazingly fast. 3. IEditableObject in DataRowView gives begin/end edit semantics. While coding lots of Entity Framework 4 over the last several weeks I often have to materialize a collection of entities and send them up to the UI for display in grids or pickers. The EF4 context only allows materializing T[] arrays or ListT of entities, and these are woeful compared to DataView and DataRow, they don't any of the three lovely features listed above. I have resorted to converting my EF4 query results from raw DbDataRecord back to DataRow so I get all the functionality back. Why do I have to do this workaround? Am I missing some other technique? Note, the entities and collections created by netTiers support all the interfaces that the System.Data classes do, so it's only after migrating to EF4 that I'm hitting this irritation. It seems that I'm taking a step backwards with EF4 entities and hence doing stupid workarounds like converting to System.Data objects. I'm told there is an MSDN EF4 discussion group, so I'll ask about this in there once I find it and get in. Greg
RE: System.Data classes and ListT
Hi Davy Have you looked at EF4.1 Code first release? I am wondering if it would alter your thinking on prefering Nhibernate for new projects Kirsten _ From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of djones...@gmail.com Sent: Wednesday, 20 July 2011 11:00 PM To: ozDotNet Subject: Re: System.Data classes and ListT Hi, At the moment, at work, there are three projects running and the one that I support. Legacy app. Uses datasets everywhere. Pros. Very fast, readonly application. Cons. Impossible to debug / modify, data is often loaded behind the scenes which cause temporary database table locks .Net 4 with EF Pros. Developpers very engaged with the project, lots of sexy tech. Cons It's been in development now for 6 months and very little visible progress has been made. One screen is done with what ammonts to a single select * .Net 3.5. Nhibernate Pros Works very well, transparent for ui developpers. Cons Misconceptions with heriacical classes in nhibernate has made it impossible to modify the data source. we have hundreds of work arounds to solve the inheritance problems. .Net 3.5 using datasets mapped to objects. Pros. Very easy to use, easy to maintain and add functionality. Cons. The code base is easily twice as big as the other projects Personally, if I was doing a new website. I would use nhibernate Web interface for existing database, ef. Stand alone Application, ado datasets and map to objects. Davy. When all you have is a hammer, every problem looks like a nail. I feel much the same way about xml _ From: Greg Keogh g...@mira.net Sender: ozdotnet-boun...@ozdotnet.com Date: Wed, 20 Jul 2011 17:55:23 +1000 To: 'ozDotNet'ozdotnet@ozdotnet.com ReplyTo: ozDotNet ozdotnet@ozdotnet.com Subject: System.Data classes and ListT Folks, I get the impression that the DataSet and its child classes classes are falling out of favour, is that true? However, I personally find them to be very convenient and full-featured for apps of all sizes (but I don't expose them to the outside world of course and my discussion here is only about private use). What I like about DataView and DataRow are the huge number of interfaces they support, and for me the most important features are these: 1. When bound to a grid you get bi-directional sorting with no code at all. 2. They supports SQL-like filter expressions (Foo Like '%bar%') AND (FooId 666) for example, and applying these filters is blazingly fast. 3. IEditableObject in DataRowView gives begin/end edit semantics. While coding lots of Entity Framework 4 over the last several weeks I often have to materialize a collection of entities and send them up to the UI for display in grids or pickers. The EF4 context only allows materializing T[] arrays or ListT of entities, and these are woeful compared to DataView and DataRow, they don't any of the three lovely features listed above. I have resorted to converting my EF4 query results from raw DbDataRecord back to DataRow so I get all the functionality back. Why do I have to do this workaround? Am I missing some other technique? Note, the entities and collections created by netTiers support all the interfaces that the System.Data classes do, so it's only after migrating to EF4 that I'm hitting this irritation. It seems that I'm taking a step backwards with EF4 entities and hence doing stupid workarounds like converting to System.Data objects. I'm told there is an MSDN EF4 discussion group, so I'll ask about this in there once I find it and get in. Greg
RE: System.Data classes and ListT
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
Re: System.Data classes and ListT
My love affair with datasets fell away as I improved as a programmer... We initially used data-sets in a failing project years ago early in the .Net days. It was a nightmare to maintain - and the underlying database schema wasn't settled. Due to the lack of strong typing in data-sets a change in column names often went undetected and caused all sorts of issues down-stream. Then there were several memory leaks that datasets were responsible for. And datasets are so heavy - our application was more memory intensive than Outlook (and that's saying a lot) - and we had many complaints from users. We also found they caused deadlocks in the database even with just a hundred users or so. Never again - we went back to straight ADO.Net into plain old class objects (POCOs), and the simplicity was a breath of fresh air. Initially we missed the niceties of datasets - get / set xml, sorting, and filtering. We quickly created helper classes / code snippets to add these things. Data-binding has never been particularly compelling in .Net (maybe I'm just still scarred from the VB6 days?) - but it simply never 'worked' with validation anyway. And we realized the real issue was proper separation of concerns - we were linking data-base objects directly to the UI; although admittedly client/server had been all the rage in the years before. We'd written a 'data-driven application' that Microsoft seemed to railroad you into (probably to keep it RAD like), but we weren't designing things properly. Essentially the application just seemed 'clunky'. With a major version release we redesigned out software from scratch with proper logical layers and separated concerns. While it initially took longer to develop, in the long run we had much more agile and maintainable code. Our IT manager even made a point to other teams that our software's maintenance cost was the lowest even though our project was one of the largest. I then left the company onto greener pastures... but a funny thing happened the other day. I met a lady in the pub who turned out was one of that companies clients. I mentioned I wrote that piece of software, and she said that it's still used today, and holds its own - even though it must be over 5 years old now. Back on topic: These days with LINQ I'm not sure datasets give you functionally more anyway. These days I still tend to use LINQ2SQL for its straight-forward data-access although I'm about to try my first project with EF4.1 code-first. I wouldn't dream of going back to datasets. Nathan. On Thu, Jul 21, 2011 at 8:24 AM, Greg Keogh g...@mira.net wrote: 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
