C #: Что еще вы используете помимо DataSet

I've found myself increasingly unsatisfied with the DataSet/DataTable/DataRow paradigm in .Net, mostly because it's often a couple of steps more complicated than what I really want to do. In cases where I'm binding to controls, DataSets are fine. But in other cases, there seems to be a fair amount of mental overhead.

I've played a bit with SqlDataReader, and that seems to be good for simple jaunts through a select, but I feel like there may be some other models lurking in .Net that are useful to learn more about. I feel like all of the help I find on this just uses DataSet by default. Maybe that and DataReader really are the best options.

I'm not looking for a best/worst breakdown, just curious what my options are and what experiences you've had with them. Thanks!

-Eric Sipple

20.08.2008 18:36:02

С тех пор, как вышел .NET 3.5, я использовал исключительно LINQ. Это действительно так хорошо; Я не вижу причин использовать какие-либо из этих старых костылей больше.

Как бы ни был хорош LINQ, я думаю, что любая система ORM позволит вам избавиться от этого дрека.

20.08.2008 18:38:04
Вы имеете в виду LINQ To SQL (он же L2S)?
rohancragg 11.12.2009 15:50:34
Очевидно, так как мы говорим о доступе к базе данных. Хотя LINQ ко всему остальному так же хорош.
TheSmurf 16.12.2009 03:21:41

Мы отошли от наборов данных и построили наши собственные объекты ORM на основе CSLA . Вы можете выполнить ту же работу с помощью DataSet, LINQ или ORM, но ее повторное использование (как мы обнаружили) намного проще. «Меньше кода, делай счастливее».

20.08.2008 18:41:34

Я широко их использую, но я не использую какие-либо «продвинутые» функции, которые Microsoft действительно продвигала, когда впервые появилась платформа. Я просто использую их как списки хеш-таблиц, которые я считаю совершенно полезными.

Я не видел хороших результатов, когда люди пытались создать сложные типизированные наборы данных или пытались на самом деле установить отношения внешнего ключа между таблицами с помощью наборов данных.

Конечно, я один из странных, который на самом деле предпочитает DataRow экземпляру объекта сущности.

20.08.2008 18:44:33

До linq я использовал DataReader для заполнения Списка моих собственных объектов домена, но после linq я использовал L2S для заполнения объектов L2S или L2S для заполнения объектов домена.

Как только у меня появится немного больше времени на исследование, я подозреваю, что объекты Entity Framework станут моим новым любимым решением!

20.08.2008 18:52:02

Мне надоели наборы данных в .Net 1.1, по крайней мере, они оптимизировали его, чтобы он больше не замедлялся как экспоненциально для больших наборов.

Это всегда была довольно раздутая модель - я не видел много приложений, которые используют большинство ее функций.

SqlDataReader был хорош, но я имел обыкновение оборачивать его в IEnumerable<T>где T было типизированное представление моей строки данных.

Linq - намного лучшая замена по моему мнению.

20.08.2008 18:55:33

I just build my business objects from scratch, and almost never use the DataTable and especially not the DataSet anymore, except to initially populate the business objects. The advantages to building your own are testability, type safety and intellisense, extensibility (try adding to a DataSet) and readability (unless you enjoy reading things like Convert.ToDecimal(dt.Rows[i]["blah"].ToString())).

If I were smarter I'd also use an ORM and 3rd party DI framework, but just haven't yet felt the need for those. I'm doing lots of smaller size projects or additions to larger projects.

20.08.2008 19:24:43

DataSets are great for demos.

Я не знаю, что делать с одним, если ты заставишь меня его использовать.

Я использую ObservableCollection

Затем я снова в пространстве клиентских приложений, WPF и Silverlight. Таким образом, передача набора данных или данных через службу - это ... брутто.

DataReaders быстрые, так как они являются прямым потоком из набора результатов.

20.08.2008 21:32:47

Selecting a modern, stable, and actively supported ORM tool has to be probably the single biggest boost to productivity just about any project of moderate size and complexity can get. If you're concluding that you absolutely, absolutely, absolutely have to write your own DAL and ORM, you're probably doing it wrong (or you're using the world's most obscure database).

If you're doing raw datasets and rows and what not, spend the day to try an ORM and you'll be amazed at how much more productive you can be w/o all the drudgery of mapping columns to fields or all the time filling Sql command objects and all the other hoop jumping we all once went through.

I love me some Subsonic, though for smaller scale projects along with demos/prototypes, I find Linq to Sql pretty damn useful too. I hate EF with a passion though. :P

21.08.2008 03:05:11

I've been using the Data Transfer Objects pattern (originally from the Java world, I believe), with a SqDataReader to populate collections of DTOs from the data layer for use in other layers of the application. The DTOs themselves are very lightweight and simple classes composed of properties with gets/sets. They can be easily serialized/deserialized, and used for databinding, making them pretty well suited to most of my development needs.

22.08.2008 19:47:15

Я НИКОГДА не использую наборы данных. Это большие тяжеловесные объекты, которые можно использовать только (как кто-то здесь указал) для "demoware". Здесь представлено много отличных альтернатив.

19.09.2008 16:16:06
«Тяжелые предметы»? Этот термин действительно имеет какое-либо значение?
Ryan Lundy 19.11.2009 20:07:22
Да, здесь есть значительный смысл. Сериализуйте набор данных, содержащий всего несколько строк, в XML-файл и посмотрите, насколько он велик. Затем создайте простой объект передачи данных (ответ Джесси). Просто определите простой класс с членами для каждого столбца, а затем класс List <DTO>. Сериализуйте это в файл XML - и посмотрите на разницу.
fuzzbone 25.11.2009 17:02:16
If you're really serializing DataSets, and then passing them over the wire or something, and there's a genuine performance problem, that's one thing. But I've seen "DataSet bloat" used as justification for making hideous, string-literal-laden code that uses DataReaders everywhere in far too many shops I've worked in.
Ryan Lundy 11.12.2009 15:32:01
Certainly replacing one bad implementation with another is a lousy solution - but I've yet to see a solution using dataset's that can't be implemented better as more effectively without one. Datasets are usefull for "DEMOware" and a holdover from pre-.NET ADO
fuzzbone 11.12.2009 16:10:05
Теперь поймите, это заставляет меня думать, что вы мало работали с ADO.NET DataSets, и, возможно, просто не знаете о них совсем. ADO.NET DataSets отключены; они контейнеры для данных. Они обеспечивают такие вещи, как отношения с базой данных и обнуляемость, поэтому у них так много методов и свойств, которые люди называют «раздутыми». Я могу понять, почему люди не предпочитают их как стиль, но они являются хорошей альтернативой для тех, кто не возражает против более ориентированного на базу данных (нежели объектно-ориентированного) стиля.
Ryan Lundy 14.12.2009 15:53:19

I'm a huge fan of SubSonic. 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. Wonderful model, wonderful tool. 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.

For 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 [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true

Это происходит каждый раз ... Затем создайте DLL из этого каталога - это часть проекта NAnt, запущенного CruiseControl.NET, - и мы поехали. Я использую это в WinForms, ASP.NET, даже в некоторых утилитах командной строки. Это создает наименьшее количество зависимостей и наибольшую «переносимость» (между связанными проектами, например, EG).


Выше уже более года. Хотя я все еще очень люблю SubSonic, я перешел к LINQ-to-SQL, когда у меня есть возможность работать в .NET 3.5. В .NET 2.0 я все еще использую SubSonic. Поэтому мой новый официальный совет зависит от версии платформы. В случае .NET 3+, пойти с принятым ответом. В случае .NET 2.0 используйте SubSonic.

19.11.2009 20:03:13

Я использовал типизированные DataSets для нескольких проектов. Они хорошо моделируют базу данных, навязывают ограничения на стороне клиента и в целом представляют собой надежную технологию доступа к данным, особенно с изменениями в .NET 2.0 с TableAdapters.

Typed DataSets get a bad rap from people who like to use emotive words like "bloated" to describe them. 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. 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.


Некоторые здесь предполагают, что DataReaders - «быстрая» альтернатива. Но если вы используете Reflector для просмотра внутренних частей DataAdapter (которым заполнены DataTables), вы увидите, что он использует ... DataReader. Типизированные наборы данных могут иметь больший объем памяти, чем другие варианты, но я еще не видел приложение, где это имеет ощутимое значение.

Используйте лучший инструмент для работы. Не принимайте решение на основе эмоциональных слов, таких как «грубый» или «раздутый», которые не имеют фактической основы.

11.12.2009 15:42:18
I'm not sure your comment is valid - a DataSet is populated via a DataAdaptor that uses a DataReader but when is the data available? If you have to wait until the read of all rows is completed, of course it has to be slower.
Andy Dent 2.06.2010 06:24:34
It depends on what you're doing with the data, though. Maybe you're processing a large set of data row-by-row; maybe you're operating on the full set and can't do anything till you have it all anyway. Maybe you're getting the equivalent of one row, and it doesn't matter which you use. Always eschewing DataSets is premature optimization. And if you need to edit and persist data, DataSets are much easier to work with than DataReaders and temporary objects. To avoid them is to obfuscate your code for no reason.
Ryan Lundy 5.06.2010 16:58:52

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. It took me awhile to get used to how allow of it worked. I have written custom components that leverage the stack as ADO.NETdid not quite give me what I really needed. One such component compares DataSets and then updates backend stores. 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.

I use ADO.NET binding in Winforms and I also use the code in console apps. 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 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.

2.10.2011 18:16:04