Strategie wymiany obiektów systemowych

Question

W tej chwili przystępujemy do wymiany stosu ADO.NET w naszej aplikacji C# z Linq.

Ponieważ aplikacja nie została zaprojektowana z warstwą abstrakcji danych, istnieją wywołania ADO w niemal każdej warstwie aplikacji w takim stopniu, że podział na jeden obiekt i próba przekonwertowania go do Linq oznacza, że labirynt dziur królika.

To, o co pytam, to strategie lub podejścia do radzenia sobie z takimi hurtowymi zmianami systemowymi, przy jednoczesnym zapewnieniu odpowiedniego testowania i minimalnego okresu "upuszczania narzędzi" (zmiana półki wprowadzająca zmiany w pewnym momencie i powrót do niej w późniejszym terminie; data).

Mamy bawił się z następujących czynności:

• Utwórz obiekt lustro każdego obiektu z nowym kodem = muszą utrzymać 2 bazy kodu do pełnego nawrócenia
• Poprzedź wszystkie nazwy funkcji funkcji ADO z ADO_ i tworzyć wersje Linq z oryginalną nazwą
• Mieć systemową FLAGĘ do oznaczenia, czy używać ADO czy Linq i owijać każde wywołanie ADO, jeśli (FLAG) {ADO} else {Linq} = musisz powrócić po konwersji i usunąć wszystkie ADO podaje

Każda sugestia do tej pory jest godna uznania.

Co sugerują ci faceci/dziewczęta?

UWAGA: Usunąłem z tytułu tytuł "(ADO to Link)", ponieważ szukam bardziej ogólnych odpowiedzi i praktyk, a nie ograniczam się tylko do konwersji ADO do Linq jako przykładu tutaj.

Answer 1

Przed wprowadzeniem jakichkolwiek zmian należy naprawdę zautomatyzować testy jednostkowe. W rzeczywistości nie należy wprowadzać żadnych zmian w odniesieniu do kodu, który nie jest objęty testami jednostkowymi co najmniej w 80%.

W świecie rzeczywistym testy jednostkowe często nie istnieją. Z drugiej strony, robienie jakichkolwiek refaktoryzacji bez testów jednostkowych może całkowicie zepsuć twój kod, sprawiając, że zarządzanie będzie jeszcze mniej prawdopodobne, aby umożliwić ci dokonywanie zmian w przyszłości. Co robić?

Za pomocą narzędzia takiego jak ReSharper można rozpocząć od zastosowania niektórych "bezpieczniejszych" refaktoryzacji. Uważaj, nie ma powodu, dla którego nie powinieneś odnosić sukcesów, używając metody "Extract", aby przenieść swoje ADO.Kod NET w osobnych metodach, "Make Method Static", jeśli nie był już statyczny, następnie "Move Method" lub "Make Method Non-Static", aby przenieść metodę do oddzielnej klasy.

Po przeniesieniu kodu można rozpocząć pisanie testów automatycznych. Na tym etapie nie muszą one być "jednostkowymi testami" w ścisłym znaczeniu tego słowa. W szczególności testy te powinny być dopuszczone do pracy z bazą danych.

Gdy pozostaniesz tylko z kodem, którego nie można łatwo przetestować na jednostce, możesz bardzo ostrożnie rozpocząć testowanie tego kodu. Możesz wykonywać takie czynności, jak przekształcanie zestawów metod statycznych w metody instancji nowych klas. Można również rozpocząć wprowadzanie iniekcji zależnych, aby ułatwić testowanie za pomocą próbnych obiektów. Ale bądź ostrożny - modyfikuj kod, który nie ma zautomatyzowanych testów, a użyjesz refaktoryzacji, która może zepsuć rzeczy.

Po prawidłowym przetestowaniu kodu, , następnie można przeorganizować kod, aby lepiej zrozumieć, a następnie zmodyfikować go, aby użyć LINQ, jeśli chcesz.

Answer 2

Nadal można wykorzystać wszystkie przechowywane procedury/funkcje pierwotnie stworzone dla rozwiązania za pomocą Linq2SQL. Używając czegoś takiego jak strategie wyrażone w Micheal Feather's Working with Legacy Code, możesz utworzyć granice wokół regionów aplikacji i zaktualizować je w obrębie tych granic.

Strategia, której używałem w przeszłości, to utrzymywanie/ignorowanie bazy danych i jej obiektów. Powoli przechodzę przez różne wywołania ADO i zastępuję je wywołaniami Linq2SQL, dopóki cała aplikacja nie używa Linq2SQL. Następnie łatwiej jest przekształcić poprzednie połączenia ADO, które ujawniły i przekazały DataSet/DataTables do bardziej odpowiednich podmiotów.

Innym podejściem (dla DataSet/DataTable ciężkich rozwiązań) jest utrzymanie ADO wywołuje w miejscu i zamiast korzystać z metod przedłużających AsQueryable() i/lub OfType<T>() przekształcić DS/dt elementy do odpowiednich podmiotów, a następnie zsumować te zmiany w bardziej spójny DAL.