Стратегии замены системных объектов
Мы в настоящее время начинаем замену стека ADO.NET в нашем приложении C# с Linq.
Поскольку приложение не было спроектировано с уровнем абстракции данных, существуют вызовы ADO всюду по примерно каждому слою приложения до такого градуса, что разделение любого объекта и попытка преобразовать его в Linq означают бег по лабиринту кроличьих нор.
Что я спрашиваю, являюсь stategies или подходами к занятию такими оптовыми системными изменениями при обеспечении надлежащего тестирования и минимальный 'период ветра вниз' инструментов отбрасывания (изменения внесения полки в уведомлении моментов, и возвратитесь к нему позднее).
Мы играли со следующим:
- Создайте зеркальный объект каждого объекта с новым кодом =, должны поддержать 2 кодовых базы до полного преобразования
- Префикс все имена функций функций ADO с ADO_ и создает версии Linq с настоящим именем
- Имейте ФЛАГ в масштабе всей системы, чтобы обозначить, использовать ли ADO или Linq и перенести каждый вызов ADO с тем, если (ФЛАГ) {ADO} еще {Linq} = должен возвратиться после преобразования и удалить всех судей ADO
Каждое предложение до сих пор является вызывающим смущение.
Что делает Вас, парни/галлоны предлагают?
Примечание: Я удалил' (ADO для Соединения)' из заголовка, потому что я ищу больше универсальных ответов и методов и не только ограниченный ADO к преобразованию Linq, используемому в качестве примера здесь.
2 ответа
Перед внесением любых изменений вам действительно следует автоматизировать модульные тесты. Фактически, вы не должны вносить никаких изменений в код, который не покрыт модульными тестами хотя бы на 80%.
В реальном мире модульные тесты часто не существуют. С другой стороны, любой рефакторинг без юнит-тестов может полностью испортить ваш код, что сделает руководство еще менее склонным разрешить вам вносить изменения в будущем. Что делать?
Используя такой инструмент, как ReSharper, вы можете начать с применения некоторых более "безопасных" рефакторингов. При соблюдении осторожности нет причин, по которым вы не сможете добиться успеха в многократном использовании "Extract Method" для переноса кода ADO.NET в отдельные методы, "Make Method Static", если он еще не был статическим, затем либо "Move Method", либо "Make Method Non-Static" для переноса метода в отдельный класс.
После того как вы перенесли код, можно приступать к написанию автоматизированных тестов. На этом этапе они не обязательно должны быть "юнит-тестами" в строгом смысле этого слова. В частности, эти тесты должны иметь возможность работать с базой данных.
Когда у вас останется только код, который не может быть легко протестирован, вы можете очень осторожно начать делать этот код более тестируемым. Вы можете делать такие вещи, как превращение наборов статических методов в методы экземпляров новых классов. Вы также можете начать внедрять инъекцию зависимостей, чтобы облегчить тестирование с помощью объектов-макетов. Но будьте очень осторожны - вы изменяете код, который не имеет автоматизированных тестов, и вы будете использовать рефакторинг, который может фактически сломать вещи.
Как только вы адекватно протестируете код, тогда вы можете реорганизовать код, чтобы он имел лучший смысл, а затем модифицировать его, чтобы он использовал LINQ, если хотите.
Вы по-прежнему можете использовать все свои хранимые процедуры / функции, изначально созданные для вашего решения с помощью Linq2SQL. Используя что-то вроде стратегии, описанной в Работа с устаревшим кодом Майкла Фезера , вы можете создавать границы вокруг областей приложения и обновлять в пределах этих границ.
Стратегия, которую я использовал в прошлом, - поддерживать / игнорировать базу данных и ее объекты. Затем я медленно перебираю различные вызовы ADO и заменяю их вызовами Linq2SQL, пока все приложение не будет использовать Linq2SQL. Затем мне легче преобразовать предыдущие вызовы ADO, которые открывали и передавали DataSets / DataTables, в более подходящие объекты.
Другой подход (для тяжелых решений DataSet / DataTable) - оставить вызовы ADO на месте и вместо этого использовать методы расширения AsQueryable () и / или OfType , чтобы преобразовать элементы ds / dt в соответствующие объекты, а затем объединить эти изменения в более связный DAL.