Неправильное использование DataTable?

Question

Недавно меня попросили помочь другой команде в создании веб-сайта ASP.NET. У них уже есть значительный объем написанного кода - мне было специально предложено создать несколько отдельных страниц для сайта.

Изучая код для остальной части сайта, количество построенных DataTables выскочило на меня. Будучи относительно новым в этой области, я никогда не работал над приложением, которое использует базу данных так же сильно, как этот сайт, поэтому я не уверен, насколько это распространено. Кажется, что всякий раз, когда данные запрашиваются из нашей базы данных, результаты сохраняются в DataTable. Этот DataTable затем обычно передается сам по себе или передается конструктору. Классы, инициализированные с помощью DataTable , всегда присваивают DataTable частному/защищенному полю, однако только некоторые из этих классов реализуют IDisposable. Фактически, в тысячах строк кода, которые я просматривал до сих пор, мне еще предстоит увидеть метод Dispose, вызываемый в DataTable.

Во всяком случае, это не кажется хорошим ООП. Это то, о чем я должен беспокоиться? Или я просто уделяю больше внимания деталям, чем должен? Предполагая, что вы самые опытные разработчики, чем я, как бы вы себя чувствовали или реагировали, если бы кто-то, кто был просто назначен вам помочь с вашим сайтом, подошел к вам по поводу этой «проблемы»?

Answer 1

Datatables может использоваться для добра и зла.

Приемлемое Использование

Я хотел бы найти следующее приемлемым использование DataTable или в DataRow:

public class User 
{ 
    private DataRow Row { get; set; }; 
    public User(DataRow row) { this.Row = row; } 

    public string UserName { get { return (string)Row["Username"]; } } 
    public int UserID { get { return (int)Row["UserID"]; } } 
    public bool IsAdmin { get { return (bool)Row["IsAdmin"]; } } 
    // ... 
} 

Класс выше хорошо потому что он отображает DataRow к класс типов. Вместо того, чтобы работать со строками и нетипизированными datarows, теперь у вас есть реальные типы данных и intellisense, чтобы помочь вам. Кроме того, если ваша схема базы данных изменяется, вы можете изменить имя столбца в своем объекте, вместо того, чтобы изменять имя столбца всюду по его использованию. Наконец, вы можете сопоставить уродливые имена столбцов, такие как «dtaccount_created», с свойством «AccountCreated».

Конечно, нет оснований для написания этого класса оболочки, так как Visual Studio автоматически генерирует для вас typed datasets. Или, как альтернатива, хороший ORM, такой как NHibernate, позволяет вам определять классы, похожие на приведенные выше.

Должны ли вы использовать простой старый ADO.NET, типизированные наборы данных или полноценный ORM, зависит от требований и сложности вашего приложения. Трудно сказать, делает ли ваша команда правильную вещь, фактически просматривая пример кода.

Кроме того, я иногда считаю его полезным для списков привязок и сеток с данными, поскольку изменения в базовом datarow автоматически заставляют графический интерфейс обновляться. Если вы создаете свою собственную безопасную для типа оболочку оболочку, вам необходимо вручную реализовать интерфейсы IPropertyChanging и IPropertyChanged.

Неприемлемо Использование

К сожалению, я видел программисты используют DataTables для контейнеров, специальных классов альтернатив и т.д. Если вы видите вашу команду, делая это, бросать в них камни. Этот стиль программирования просто не работает на статически типизированном языке, и он собирается превратить развитие в кошмар.

Основная проблема с datatables: они не печатаются, поэтому вы не можете ничего с ними поделать, не давая им строку и кастинг любого загадочного объекта, который они содержат, в правильный тип. Кроме того, реорганизация имени столбца почти невозможно автоматизировать, поскольку они основаны на строках, поэтому вы не можете полагаться на intellisense, чтобы помочь вам написать правильный код, и вы не можете ловить ошибки во время компиляции.

Я говорю, доверяй своему инстинкту: если вы думаете, что дизайн чешуйчатый, это, вероятно, так.

Answer 2

да, я был бы осторожен здесь ...

я должен был заботиться о веб-приложение vb.net в течение 2 месяцев, прежде чем я мог бы переписать все в C# это .... Я люблю C#, VB заставляет меня хотеть бросить ...

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

Хуже того, бывали случаи, когда он фактически удалял DataTable в сеанс ... без всякой причины.

DataTables и т. Д. Отличные, но используйте их только в том случае, если вам действительно нужно их использовать. Разработчик был настолько плохой, что на странице поиска он фактически сбросил все 5000 продуктов из базы данных в datatable, а затем выполнил поиск в datatable вместо выполнения поиска в хранимой процедуре (то есть на SQL SERVER)

Answer 3

На на очень высоком уровне архитектура системы программного обеспечения может быть охарактеризована как использование одного из нескольких «шаблонов уровня предприятия», Transaction script, Table Model, Domain Model, или Service Layer. Если система, которую вы просматриваете, использует шаблон модели Table Model, тогда вы ожидаете увидеть больше использования DataTables и DataSets, чем, например, в системе, которая была разработана с использованием Domain Model или одного из других шаблонов.

Однако, поскольку методологии разработки программных систем развивались в течение последних нескольких лет, как правило, понималось, что сложные системы не очень хорошо используют сценарии транзакций или архитектуры табличной модели. Обычно это связано с тем, что в системах, разработанных с использованием этих шаблонов, функциональность, как правило, гораздо более переплетена и взаимосвязана, а по мере роста сложности объем функциональной или модульной взаимозависимости растет экспоненциально и становится слишком сложным для управления очень быстро. Таким образом, в зависимости от того, насколько сложна ваша конкретная система, да, вы должны быть подозрительными, если DataSets и/или DataTables используются во многих слоях системы. Это может быть признаком того, что разработчик системы использовал/использовал Табличную модель (сознательно или бессознательно), где он должен использовать архитектуру Domain Model или Service Layer.

Answer 4

Это определенно то, о чем вам следует беспокоиться - см. Связанный пост on the importance of Disposing DataTables.

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

Для измерения степени повреждения вашего приложения, вы можете взять дамп памяти с помощью WinDbg и посмотреть на огромное количество DataTable экземпляров (! Dumpheap -stat -типа System.Data.DataTable), а затем посмотреть на largest data tables in memory.

Это распространенная ошибка в приложениях ASP.NET, и та, которая может принести вам серьезные неприятности. Если вы используете общие (кэшированные) экземпляры DataTables, обратите внимание, что фильтры просмотра меняют исходный экземпляр, они не генерируют новую копию.

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

Answer 5

Использование DataTable может быть ленивым/неэффективным способом хранения данных. При этом значительные накладные расходы. Вы правы, чтобы беспокоиться, хотя разработчик (разработчики) может иметь реальную проблему, слыша, как плохо они разработали это приложение. Будет ли руководство позади вас, в целях создания продукта лучшего качества? Будет ли связанная с этим задержка в развитии тем, что они могут принять?