Преимущества и недостатки сильно типизированных наборов данных для DAL в .Net

Question

В настоящее время я работаю с системой, которая унаследовала DAL, используя сильно типизированные наборы данных .Net. Я никогда не работал с ними до этого, но я обнаружил, что у меня есть сильное отвращение к их использованию. По сравнению с DAL на основе POCO они кажутся неуклюжими, сложными в управлении, и результирующие объекты в значительной степени связаны с проблемами, связанными с конкретными базами данных (например, доступ к объектам из таблиц и строк, получение желаемых данных по ключевым значениям и т. Д. - isn «Вся цель DAL - отвлечь это от логических слоев?»).

Было проведено обсуждение перезаписи и/или повторной факторизации частей слоя базы данных. Я лично хотел бы, чтобы эти наборы данных были удалены, но мне сложно убедить некоторых из моих коллег, которые привыкли использовать их.

Каковы некоторые из плюсов и минусов использования сильно типизированных наборов данных против DAL на основе POCO? Я оправдан в своем отвращении к строго типизированным наборам данных или согласен с сообществом, что у них нет проблемы? Есть ли какие-то другие решения, которые мне не хватает?

Хотя я также согласен с тем, что есть преимущества использования структуры ORM, такой как NHibernate, я думаю, что библиотека этой сложности будет трудно продать моим коллегам. Если кто-то может предоставить достаточный аргумент в этом направлении, я бы хотел его услышать.

Answer 1

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

Вы можете представить их как переходный этап между сырым ADO.NET с DataSets, DataTables и DataAdapters и Entity Framework. Я попытался бы представить Entity Framework, используя создание первого кода конструктора и базы данных в качестве замены существующего метода для ваших коллег. Это должно быть знакомым образцом и позволит им легче перейти. Он также должен быть самым низким объемом дополнительной работы по модернизации существующего кода.

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