Обновление уровня данных приложения .NET

Question

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

В настоящее время в нем используется система с бизнес-объектами, которые все основаны на / расширении DataRow объектов, то есть - каждый объект больше илименьше относится к одной строке в базе данных.Приложение в настоящее время НЕ является объектно-ориентированным, но это вызывает много проблем, и мы хотим двигаться в направлении OO.

Поэтому мы собираемся начать использовать .NET Entity Framework и создать файл .edmx.Идея состоит в том, чтобы просто перетащить все таблицы базы данных SQL в конструктор .edmx и позволить ему создавать связанные с ним объекты данных.

Теперь, на мой взгляд (как OO-разработчик), я планировал вручную создать новыйбизнес-объекты и заполняют их из сгенерированных .edmx объектов данных, возвращаемых запросами в новом слое данных.Это позволило бы просто разделить различные слои с помощью интерфейса.

Проблема в том, что босс говорит, что не хватает времени переписать сто или около того классов бизнес-объектов, и предлагает использовать сгенерированный .edmx.объекты данных во всем приложении.

Каждая мысль в моей голове говорит: «Нет ... не создавайте эту связь между уровнем данных и всей системой», но начальник говорит, что он видел статьи в Интернете, продвигающие это.

Итак, мои вопросы к вам, ребята, таковы: (просьба указать веские причины для ваших ответов на вопросы 1 и 2)

1. Является ли это жизнеспособным решением (даже краткосрочным)?

2. Есть ли лучшее / альтернативное решение для создания отдельных бизнес-объектов из сгенерированных объектов данных?

3. Есть ли лучший / более простой способсоздавать отдельные бизнес-объекты из сгенерированных объектов данных, а не копировать и вставлять вручную?

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

Answer 1

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

Не вижу смысла в том, что вы создаете "сотни" бизнес-объектов и копируете данные из объектов данных EF в свои? Вы все еще взаимодействуете с EF и вашими бизнес-объектами!

Чтобы пройти со связью, IoC следует использовать там, где вы можете рассмотреть возможность отделения от уровня доступа к данным от бизнес-уровня. И, безусловно, вы можете переключать ORM с очень небольшими затратами времени. Это красота separation of concern.

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

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

А в вашем случае вы можете рассмотреть EF Code First. Это определенно даст вам лучшее представление, чем «База данных в первую очередь» в вашей структуре слоя доступа к данным.

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

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

Попробуйте определить основные компоненты, и DAL должен быть одним из тех, которые должны быть обновлены.

Answer 2

Проблема в том, что босс говорит, что не хватает времени переписать сто или около того классов бизнес-объектов, и он предлагает используя сгенерированные объекты данных .edmx по всему применение.

1. Является ли это жизнеспособным решением (даже краткосрочным)? &
2. Есть ли лучшее / альтернативное решение для создания отдельных бизнес-объектов из сгенерированных объектов данных? &
3. Есть ли лучший / более простой способ создания отдельных бизнес-объектов из сгенерированных объектов данных вместо ручного копирования и вставки?

ANS: Вы можете попробовать Sybase PowerDesigner , который может выполнить обратный инжиниринг и сгенерировать код C # для вас. Или вы можете попробовать CodeSmith , чтобы сгенерировать код для вас. Эти инструменты экономят ваше время.

Существуют и другие платформы, такие как Developer Express XPO и DataObjects.Net и т. Д. ... или LLBLGen Pro , которые можно попробовать.

Answer 3

Когда я начал разрабатывать свое текущее приложение, я решил использовать Code First, чтобы не создавать гигантский edmx.Я читал, что они вносят улучшения в этот конструктор (разделяя его и т. Д.), Но, как это было, я не хотел пытаться использовать edmx из-за 100+ объектов, которые мы должны создать.

Я разработал небольшое приложение для чтения таблицы и создания объектов POCO для кода вначале (я думаю, что сейчас есть инструменты для этого), а затем создал класс, представляющий контекст, содержащий Inb DbSet для всех этих объектов.

Что я обнаружил, когда попытался использовать эти объекты прямо в приложении MVC на внешнем интерфейсе, так это то, что у меня возникли проблемы с сериализацией, когда я пытался поместить их в таблицы (интенсивное использование сериализации json) с проблемами циклических ссылок.Итак, я решил создать ViewModel и в тех случаях, когда мне не нужна скорость, использовать такой инструмент, как AutoMapper, чтобы отобразить Table <-> ViewModel.В тех случаях, когда мне нужна скорость (например, экраны списков), я написал реальный запрос linq, чтобы преобразовать результаты в объект модели представления.Единственная проблема, с которой я сталкиваюсь, заключается в том, что модели обзора должны быть очень плоскими.

Не совсем ответ для вас, но некоторый опыт прохождения через это.