Создание слоя доступа к данным с нуля и автоматически созданного слоя доступа к данным Visual Studio - PullRequest
0 голосов
/ 13 января 2012

Я создал Windows Form и у меня возник вопрос:

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

Какую ситуацию должно использовать каждое решение?

1 Ответ

2 голосов
/ 13 января 2012

Существует ряд различных опций, доступных разработчику, которому необходимо добавить уровень доступа к данным (DAL) в свое приложение.Здесь я собираюсь предположить, что когда вы говорите «Visual Studio может генерировать код для этого», вы имеете в виду Microsoft Entity Framework (EF), которую вы можете использовать для создания бизнес-объектов и репозиториев из схемы (и наоборот).,Существуют и другие способы использования VS для создания уровня доступа к данным (например, использование шаблонов T4 и генерация кода).Вот некоторые из факторов, которые влияют на выбор уровня доступа к данным:

  • Время.Наверное, самый большой фактор (на мой взгляд).Существует множество ссылок для изучения соглашений, необходимых для начала работы с уровнем данных EF за очень короткое время.Это чрезвычайно быстрый путь для ввода данных в ваше приложение.В прошлом, просто загружая и сохраняя данные из постоянного хранилища, существующие платформы, такие как EF, позволяют быстро поддерживать такие вещи, как транзакции и кэширование.Если вы напишите свой собственный DAL, то, вероятно, потребуется больше времени для извлечения данных из хранилища данных, и, безусловно, потребуется больше времени для его тестирования до такой же степени, как доказано EF.
  • Особенности.Вы получаете много возможностей "из коробки" с EF.Это займет некоторое время, чтобы добавить их в свой DAL.
  • Опыт.Существует множество ловушек при написании собственного слоя DA с нуля - зачем изобретать велосипед?Написание хорошего DAL с нуля требует некоторого опыта кодирования, чтобы преуспеть (но это большой опыт обучения и очень приятный проект для работы)
  • Контроль.Вы можете написать свой собственный DAL, если вы предпочитаете контролировать каждый аспект кода.Несмотря на то, что такая структура, как EF, может быть настроена разными способами и будет работать для многих приложений, в частности простых, более сложные требования большого приложения (будь то вычислительно сложные или с конкретным профилем производительности) могут лучше подходить для болеенастраиваемый пользовательский DAL.Например, вам может не понравиться SQL, сгенерированный EF, или вам не нравится способ загрузки дочерних моделей.Существует множество DAL с открытым исходным кодом, которые обеспечивают прочную основу для легкого подключения к любому аспекту DAL.
  • Существование устаревшего кода.В некоторых крайних случаях, если вы работаете в существующем приложении и вам необходимо соответствовать существующим требованиям интерфейса или соответствовать существующим шаблонам загрузки данных, вам может оказаться проще создать собственный слой DA.Предпочтительной альтернативой здесь будет написание слоя адаптера для адаптации вашего DAL к существующим требованиям приложения, таким образом отделяя ваш уровень DA от требований унаследованного кода.

Если вы планируете написать свой собственный DAL,Я определенно рекомендую взглянуть на существующие варианты генерации кода.Запланируйте частую смену схемы и быстро восстановите пользовательский DAL.Такие инструменты, как Code Smith, MyGeneration и шаблоны T4 в VS, могут помочь при написании DAL с нуля.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...