2011-01-31 4 views
1

Это веб-приложение, основанное на виде библиотеки доступа к данным (простые объекты данных и связанные объекты для выполнения операций CRUD на них), которые генерируются непосредственно из базы данных.Модернизация библиотеки доступа к данным «Hand Rolled»

Так из таблицы Person

ID
Forename
Surname
DoBirth

вы получите сгенерированный класс Person с полями:

ID, Forename, Surname, DoBirth набраны из своих БД столбцов.

И вспомогательный класс PersonPersister

с

Create(Person p) 
Update(Person p) 
Delete(Person p) 

методов.

Он также создаст необходимые CRUD sprocs в базе данных.

Мне было неловко об этом, когда я начинал как, кроме коротких флирта с nHibernate и MEF, я привык к ручному кодированию моего уровня данных. Все мои заботы, похоже, приносят плоды сейчас, год спустя, когда мы делаем еще один этап разработки с большой командой разработчиков, и трещины начали появляться.

Основная проблема заключается в том, что в качестве разработчиков мы не имеем никакого контроля над сгенерированными и нет возможности для версии DAL.

Каждый раз, когда мы делаем выпуск, мы много времени настраиваем вручную приложение, dal и databse, чтобы заставить его работать. Часто сценарий - это тот, в котором DAL был сгенерирован с dev db, а затем применен к live db, который, конечно же, не имеет таблиц/sprocs и т. Д., Созданных во время разработки.

В это время я часто нахожу, что перехожу на joberve.com, хотя этот вопрос в стороне, скорее, мне нравится работать здесь.

Идеи, которые у меня были, включают в себя модификацию кодегенератора, чтобы он перезаписывал исходные файлы в явном проекте DAL-обработки Visual Studio - они затем отслеживались в CVS, а также редактировались вручную. Есть ли у кого-нибудь положительный опыт такой стратегии? На данный момент единственным артефактом, созданным сборкой, является dll, поэтому просмотр изменений невозможен.

Помимо использования ORM (управление не является вентилятором - да, я знаю), каковы наши варианты, насколько это необходимо для того, чтобы дать возможность контролировать себя? Нам по-прежнему нужен элемент автоматизации, но количество, которое у нас есть, в настоящее время неработоспособно.

Нам очень повезло, что здесь есть подписки MSDN, поэтому мы запускаем TFS 2010 с автоматическими сборками, последней версией Visual Studio и т. Д., Но из-за этого аспекта нашей среды разработки, похоже, что мы за десятилетие или больше.

+1

Звучит как много отбросов ко мне.Я работал над проектом, где разработчики обязаны обновлять SQL-релиз «выпуска» каждый раз, когда они совершают код, влияющий на схему базы данных. (сценарий был проверен и применен к базе данных клиента как часть цикла выпуска) – Matt

+0

«Churn» - это один из способов его описания: -o – 5arx

ответ

2

Как насчет проекта базы данных, который хранит все ваши хранимые процедуры ...

Pros

  1. контроля версий БД
  2. Easy deployment..You просто должны указать, какие базы данных она переходит к и с 1 клик и может развернуть его ...
  3. Вы знаете точно, что меняется как результат введения нового класса
  4. Весь код базы данных содержит вместе с другой код и доступен от one IDE, что делает его намного проще отправить в изменениях сразу ..

Против

  1. Вы, возможно, придется тратить время на перенастройки настоящую инфраструктуру, которая создает хранимую проки на что-то который создает хранимые файлы сценариев proc ... В основном весь код в пределах создания/обновления/удаления У вас упоминалось должно быть , написанное снова.

и многое другое за и против которых вы будете лучше судить ...

Если вы собираетесь рассмотреть этот вариант вы должны смотреть на эти ссылки ниже

  1. Beginner's tutorial
  2. Sample Project
+0

Это звучит хорошо - не думайте, что у вас есть ссылка на пример/учебник, вы ...? – 5arx

+1

@ 5arx: отредактированный ответ ... посмотрите – Mulki

+0

Прохладный спасибо. У меня будет гусак. – 5arx

3

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

+0

Я бы сказал, что он немного больше, но больше на dev, чем на стороне развертывания вещей, которые я использовал для использования SQL Delta для синхронизации dev db -> staging -> production, это не особенно обременительно. Проблема больше связана с тем, что разработчики вносят изменения в db, запускают код и записывают на заказ код, основанный на объектах во вновь создаваемом «DAL», который, конечно, ссылается на объекты/столбцы и т. Д., Которых нет в живой базе данных , – 5arx

2

В прошлом я работал с инструментами генерации кода и использовал их для ge nerate, который был включен как часть проекта Visual Studio, а затем изменен вручную в соответствии с требованиями. Это означало, что генерация кода была всего лишь шагом экономии времени, и источник был полностью контролирован версией.

Это звучит как хороший первый подход, так как вы должны сделать перезапись файла, о которой вы говорите, тогда вы получите очевидные преимущества управления версиями и правильного цикла выпуска QA'd.

1

Здесь есть две проблемы: ваша DAL и стратегия развертывания.

Для решения одного развертывания, вы должны взглянуть на Fluent Migrations

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

Вы можете свободно использовать API, встроенные SQL-скрипты, встроенный SQL - все, что работает для вас. Вы также можете легко включить миграцию в процесс автоматической сборки.

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