DataLayer в Linq с другой версией модели данных

Question

Я хотел спросить SO-сообщество об этой проблеме в моем проекте. У меня есть проект Silverlight App в SL 3.0, который на данный момент имеет классический дизайн с бизнес-уровнем и уровнем данных в Linq2SQL. Проблема в том, что модель данных может быть в другой версии с небольшими изменениями между ними.

У меня есть 2 решения, но ни одно из них не показалось хорошим:

1. Избавьтесь от Linq и поставьте старые хранимые процедуры:

   • хорошая точка, если модель данных меняется, мне просто нужно изменить хранимые процедуры
   • плохая часть в том, что мой linq с динамическими фильтрами даст мне 30 хранимых процедур для изменения

2. Создание одного слоя данных для каждой версии

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

Есть ли хороший шаблон для отслеживания доступности уровня данных?

Answer 1

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

Answer 2

Я бы согласился с К. Россом. Одна из замечательных особенностей использования Linq (если не единственного) заключается в том, что для обновления модели требуется всего лишь щелчок мыши, тогда как в старые времена с помощью хранимых процедур для распространения изменений схемы через различные уровни персистентности и уровни данных могли потребоваться часы ,

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

Answer 3

Вы также можете использовать бизнес-объекты для смягчения этого, делая объекты SQL объектов LINQ 2 DTO. Хотя больше работы (которую можно уменьшить с помощью T4 или codemith), новые объекты на бизнес-уровне получают объектный код LINQ to SQL, а пользовательский интерфейс использует эти объекты DTO для привязки данных.

Затем уловка заключается в том, что при обновлении вам потребуется больше кода, чтобы затем взять бизнес-объект, запросить объект LINQ и передать данные из бизнес-объекта в объект LINQ и зафиксировать изменения. Немного больше работы и здесь.

Но таким образом вы можете иметь несколько моделей LINQ, но только один бизнес-объект, который либо имеет все свойства всех моделей, либо имеет свойства, которые изменяются в коллекции словарей или другом механизме (возможно, дочернем объекте). ?).

Есть способы обойти подобные вызовы.

НТН.