Some here suggest that DataReaders are the "fast" alternative. But what I've found is that if for whatever reason you can't or don't want to use an O/R mapper, typed DataSets are a good solid choice that are easy enough to use and will get you 90% of the benefits of an O/R mapper. I'll grant that I like using a good O/R mapper more than using DataSets it just "feels" better to use objects and collections instead of typed DataTables, DataRows, etc. Typed DataSets get a bad rap from people who like to use emotive words like "bloated" to describe them. They model the database well, enforce constraints on the client side, and in general are a solid data access technology, especially with the changes in. I've used typed DataSets for several projects. I searched today for replacement to ADO.NET and I do not see anything that I should seriously try to learn to replace what I currently use. I most recently have teamed with another developer to create a custom ORM that we used against a crazy datamodel that we were given from contractors that looked nothing like our normal data stores. I use ADO.NET binding in Winforms and I also use the code in console apps. I really know how all of these items work well and those that have seen what I have done are very impressed that I managed to get beyond there feel that it was only useful for demo use. One such component compares DataSets and then updates backend stores. I have written custom components that leverage the stack as ADO.NETdid not quite give me what I really needed. It took me awhile to get used to how allow of it worked. I have used typed and untyped DataSets, DataViewManagers, DataViews, DataTables, DataRows, DataRowViews, and just about anything you can do with the stack since it firsts came out in multiple enterprise projects. ![]() So my new official advice is platform version-dependent. While I still hold great fondness in my heart for SubSonic, I have moved on to LINQ-to-SQL when I have the luxury of working in. This generates the fewest dependencies and the greatest "portability" (between related projects, EG). I'm using that in WinForms, ASP.NET, even some command-line utils. Then build the DLL off that directory - this is part of an NAnt project, fired off by CruiseControl.NET - and away we go. The site makes it sound like an ASP.NET deal, but generally speaking it works wonderfully just about anywhere if you're not trying to use its UI framework (which I'm moderately disappointed in) or its application-level auto-generation tools.įor the record, here is a version of the command I use to work with it (so that you don't have to fight it too hard initially): sonic.exe generate /server /db /out /generatedNamespace /useSPs true /removeUnderscores true A well-written batch/CMD file can generate an entire object model for your database in minutes you can compile it into its own DLL and use it as needed.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |