Это веб-приложение, которое опирается на своего рода библиотеку доступа к данным (простые объекты данных и связанные объекты для выполнения над ними операций CRUD), которая генерируется непосредственно из базы данных.
То есть из таблицы Person
ID<br>
Forename<br>
Surname<br>
DoBirth
вы получите сгенерированный класс Person с полями:
ID, Forename, Surname, DoBirth, набранный из их столбцов БД.
И помощникКласс PersonPersister
с
Create(Person p)
Update(Person p)
Delete(Person p)
методами.
Это также создаст необходимые CRUD-спроки в базе данных.
Мне было неловко, когдаЯ начал с того, что кроме кратких заигрываний с nHibernate и MEF я привык вручную кодировать свой уровень доступа к данным.Все мои опасения, похоже, осуществляются сейчас, через год, когда мы находимся на другом этапе разработки с большой командой разработчиков, и трещины начали появляться.
Основная проблема заключается в том, что как разработчикимы не имеем никакого контроля над тем, что сгенерировано, и у нас нет способа версии DAL.
Каждый раз, когда мы выпускаем релиз, мы много времени настраиваем приложение, dal и databse, чтобы оно работало.Часто это тот сценарий, в котором DAL был сгенерирован из базы данных dev, а затем применен к живой базе данных, которой, конечно, не хватает таблиц / sprocs и т. Д., Созданных во время разработки.
В эти моменты я часто нахожуЯ сам направляюсь на jobserve.com, хотя мне больше нравится работать над этим вопросом.
Идеи, которые у меня были, включают в себя модификацию генератора кода, чтобы он перезаписывал исходные файлы в явном проекте Visual Studio, работающем с DAL, - тогда их можно было бы отслеживать в CVS, а также редактировать вручную.У кого-нибудь есть положительный опыт такой стратегии?На данный момент единственным артефактом, который генерирует сборка, является dll, поэтому просмотр истории изменений невозможен.
Помимо использования ORM (управление не фанат - да, я знаю), каковы наши варианты, какнасколько рационализировать это, чтобы дать себе контроль?Нам по-прежнему нужен элемент автоматизации, но в настоящее время его количество неосуществимо.
Нам очень повезло, что у нас есть подписки MSDN, поэтому мы запускаем TFS 2010 с автоматическими сборками, последней версией Visual Studio и т. Д.и т. д., но из-за этого аспекта нашей среды разработки создается впечатление, что мы отстали на десятилетие или более.