В настоящее время мы находимся в ситуации, когда у нас есть выбор между использованием готового объектно-реляционного картографического модуля или развертыванием собственного
У нас есть устаревшее приложение (ASP.NET + SQL Server), где, к сожалению, уровень данных и бизнес-уровень объединены. Система не особенно сложна с точки зрения доступа к данным. Он считывает данные из большой группы (35-40) взаимосвязанных таблиц, манипулирует ими в памяти и сохраняет их в некоторых других таблицах в сводном формате. Теперь у нас есть возможность провести некоторый рефакторинг, и мы ищем подходящие технологии для разделения и правильной структуры нашего доступа к данным.
Какие бы технологии мы ни выбрали, мы бы хотели:
- есть объекты POCO в нашей доменной модели, которые являются невежественными
- иметь уровень абстракции, позволяющий нам проводить модульное тестирование объектов нашей доменной модели на основе макета источника данных
Очевидно, что по этому поводу уже есть много вещей, таких как Patterns & Frameworks и т. Д.
Лично я настаиваю на использовании EF в сочетании с модулем ADO.NET Unit Testable Repository Generator / POCO Entity Generator . Он удовлетворяет всем нашим требованиям, может быть легко встроен в шаблон Repo / UnitOfWork, и наша структура БД достаточно развита (уже подверглась рефакторингу), так что мы не будем вносить ежедневные изменения в модель.
Однако другие в группе предлагают полностью / с нуля создать / развернуть наш собственный DAL. (Пользовательские DataMappers, DataContexts, Репозиторий, Интерфейсы повсюду, Избыток внедрения зависимостей для создания конкретных объектов, Пользовательский перевод LINQ-в-основополагающих запросов, Пользовательские реализации кэширования, Пользовательские реализации FetchPlan ...) список можно продолжать и быть откровенным я как безумие
Некоторые аргументы были выдвинуты: «Ну, по крайней мере, мы будем контролировать наш собственный код» или «О, я использовал L2S / EF в предыдущем проекте, и это были только головные боли». (Хотя я раньше использовал и в Production, и обнаружил, что любые проблемы встречаются редко и очень легко решаются)
Так что у любого из ваших опытных разработчиков / архитекторов есть какие-то мудрые слова, которые могут помочь мне отвлечь этот продукт от того, что, как мне кажется, будет полной катастрофой. Я не могу не думать, что любая выгода, полученная путем уклонения от проблем EF, будет потеряна так же быстро, если попытаться заново изобрести колесо.