Лучший класс C # обобщений для замены DataTable в качестве коллекции?

Question

Я пытаюсь вывести устаревшее приложение C # .NET 1.1 в современную эпоху. Мы используем DataTables для наших коллекций того, что могло быть бизнес-объектом.

Учитывая, что большая часть кода думает, что взаимодействует с интерфейсом DataRow, какая универсальная коллекция сделает для наименее болезненного перехода?

Answer 1

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

хорошо, я бы рассмотрел список <>

где ваши методы принимают IList <> (для доступа к индексу) или IEnumerable <> (для использования цикла foreach в коллекции)

например

private void PrintAll<T>(IEnumerable<T> items)
{
    foreach(T item in items)
        Console.WriteLine(item.ToString());
}

теперь я могу передать в любой контейнер, который использует интерфейс IEnumerable <>, включая List <> и обычный массив

пример

List<Person> people = new List<Person>();
//add some people to the list
PrintAll<Person>(people);

образец n-уровневого приложения с объектами Buiness

НТН

кости

Answer 2

Вместо того, чтобы переходить от API-интерфейсов DataSet / DataTable, почему бы не создать подкласс DataTable и DataRow для типов, подходящих для вашей бизнес-логики?

Превосходная поддержка подклассных объектов DataRow и DataTable. Вы получите строгую типизацию в новом коде, а также обратную совместимость со своим старым кодом. Кроме того, вы можете вводить бизнес-логику, где вам нужно / нужно.

Answer 3

Самый простой способ перенести ваше «приложение в современную эпоху» - это просто обновить код с Visual Studio 2003 до 2005 или 2008. Если вы хотите добавить поведение к своим классам («что могло быть бизнес-объектами») ") тот факт, что DataSet, DataTable и DataRow реализованы как частичные классы, дает вам это.

Упомянутые выше решения теряют для вас многое, в том числе отслеживание изменений, если только это не то, что вы ищете - отклоняться в значительной степени. LINQ to SQL, Entity Framework и т. Д. Обеспечивают отслеживание изменений, но в механизме Unit of Work для подключения к БД, а не для отслеживания Unit of Work непосредственно на ваших объектах, как в DataRow.

Надеюсь, вы не просто переходите, чтобы перенести свое "приложение в современную эпоху", и что у вас есть некоторые преимущества, которые вы пытаетесь получить за функциональность, от которой вы отказываетесь, и за усилия, которые вы тратите? 1005 *

Кстати, все это предполагает, что вы используете Typed DataSets ... нетипизированные объекты DataSet, на мой взгляд, глупы для большинства применений.

Answer 4

Если вы привыкли к DataTable, возможно, вы привыкли к отслеживанию изменений и поддержке постоянства, которую предоставляют адаптеры (и т. Д.). В каком случае вы рассматривали LINQ-to-SQL и / или Entity Framework? Оба они поддерживают расширенное отслеживание изменений и автоматическое сохранение, предлагая различные другие варианты использования DAL, такие как составные запросы и все эти другие достоинства LINQ.

Определенно заслуживает расследования.

Обратите внимание, что переход к типизированным объектам POCO (т. Е. Не DataRow и не к их подклассу) по-прежнему является большим отклонением, поэтому это не будет простым изменением. Если у вас нет времени для серьезных изменений, было бы прагматично придерживаться DataTable (возможно, набрано).

Это предоставит вам EntitySet<T>, IQueryable<T> и т. Д., Или вы можете просто использовать List<T>, Collection<T> и т. Д. Для специального использования.