Najlepsze praktyki przenoszenia dużych aplikacji MS Access w kierunku .Net?

Mamy naprawdę ogromną aplikację MS Access opracowaną początkowo dla naszych osobistych potrzeb, która następnie została przekształcona w oprogramowanie komercyjne i pomyślnie sprzedana. Oprogramowanie jest rodzajem „wszechstronnego oprogramowania dla Twojej firmy” i zawiera kilka modułów, w tym system zarządzania dokumentami, planowanie zasobów przedsiębiorstwa, zarządzanie zapasami, zarządzanie relacjami z klientami, analizę danych itp. Jesteśmy bardzo zadowoleni z obecnego funkcjonalność aplikacji, ale aby spełnić prośby naszych klientów, zdajemy sobie sprawę, że musimy przejść do czegoś nowego.

Zdecydowaliśmy się stopniowo przenieść naszą aplikację w kierunku .Net, ponieważ możemy trzymać się Visual Basic .Net: mimo że jest to nowy język dla większości programistów tutaj, mamy głęboką znajomość VBA i kilkudziesięciu małych projektów wdrożonych w VB6.

Rozpoczęliśmy już przenoszenie funkcjonalności warstwy danych naszej aplikacji na MS SQL Server, aby każda manipulacja danymi i wyszukiwanie odbywały się bezpośrednio na serwerze.

Szukamy najlepszych praktyk w zakresie stopniowego przenoszenia naszego rozbudowanego interfejsu GUI (około 500–600 różnych formularzy, w tym podformularzy, około 200 raportów z obsługą wielu języków itp.). Po niedawnym żądaniu od naszego potencjalnego klienta wprowadzenia asynchronicznego szyfrowania danych na dokumentach w DMS, chętnie również całkowicie oddzielimy tę część od MS Access i wdrożymy ją w .Net.

Pytanie brzmi, jak bezproblemowo zintegrować aplikację .Net z istniejącym systemem MS Access, abyśmy mogli wywołać ją z określonymi parametrami (uprawnienia użytkownika itp.) I umożliwić wymianę danych między tą aplikacją a uruchomioną aplikacją MS Access.

EDYTOWAĆ:

Próbowaliśmy zastosować pewne praktyki z książki Martina Fowlera „ Wzorce integracji przedsiębiorstw ”, aby osiągnąć pewną integrację między aplikacją MS Access a niektórymi małymi narzędziami, które zaimplementowaliśmy w .Net dla różnych potrzeb. Ale udało nam się jedynie użyć wzorca „współużytkowanej bazy danych” i nie byliśmy bardzo zadowoleni z naszego rozwiązania.

Na przykład zaimplementowaliśmy małe narzędzie działające jako usługa systemu Windows, które automatycznie pobiera wszystkie wiadomości z serwera pocztowego za pomocą połączenia POP3 i przechowuje je w jednej tabeli, podczas gdy wszystkie załączniki są przechowywane w systemie plików.

To, co głównie zrobiliśmy, to skorzystanie z ADO.NET w celu bezpośredniego dostępu do baz danych MS Access w formacie MDB i wypełnienia tabeli niektórymi przetworzonymi danymi (np. Danymi o wiadomościach pocztowych z powyższego przykładu: mamy pola FROM, TO, CC, BCC, Temat i ciało).

Nie ma absolutnie żadnego problemu z pracą z formatem danych MDB z .Net , ponadto nie chcemy pozostać przy MDB i rozszerzyć prawie wszystko do MS SQL Server 2008 - daje nam to znacznie więcej swobody w zakresie zarządzania danymi i skalowalności.

Główny problem polega na tym , że nie wiemy, jak zaimplementować rodzaj „wywołania zwrotnego” w programie Access, abyśmy mogli uruchomić wykonanie określonego kodu VBA podczas aktualizacji danych.

Mieliśmy wielką nadzieję, że MS Access 2010 obsługuje aktualizację i wstawianie wyzwalaczy do tabel danych , ale okazało się, że możemy używać tylko makr MS Access dla tych wyzwalaczy i nie ma sposobu na wykonanie dowolnego niestandardowego kodu VBA w wyzwalaczu.

Wypróbowaliśmy również niektóre rozwiązania z wysyłaniem naciśnięć klawiszy bezpośrednio do okna MS Access, aby naśladować niektóre dane wymagane przez użytkownika. To działa, ale nie uważamy, że jest to niezawodne rozwiązanie, które można zastosować w produkcji.

Przyjrzeliśmy się także DDE dla MS Access, ale nie mogliśmy znaleźć żadnego dobrego przykładowego rozwiązania implementującego polecenia DDE i używającego ich do wymiany danych w pamięci i poleceń.

Zatem głównym problemem jest współistnienie aplikacji MS Access i .Net i interakcja między nimi.

EDYCJA 2 :

Zapomniałem wspomnieć o tym , co zaimplementowaliśmy również bibliotekę MSMQ w VBA do przesyłania wiadomości między .Net i MS Access, problemem był znowu brak oddzwaniania: naprawdę musieliśmy sondować kolejkę pod kątem nowych wiadomości i biorąc pod uwagę, że VBA tak naprawdę nie obsługuje wielowątkowość to nie było naprawdę miłe rozwiązanie.

To będzie duży i bardzo zaangażowany projekt. Byłem odpowiedzialny za migrację baz danych Access do .NET wiele razy, ale nigdy na taką skalę. Zgadzam się, że stopniowe podejście będzie prawdopodobnie najbardziej realistyczne. Próba zmierzenia się ze wszystkim jednym strzałem jest łatwym sposobem na porażkę.

Podobnie jak w innych odpowiedziach, pierwszym i najważniejszym krokiem będzie przeniesienie wszystkiego na SQL Server. Wykonując tę ​​czynność, udokumentuj bazę danych, jeśli nie zostało to jeszcze zrobione, i określ obszary do refaktoryzacji, jeśli istnieją. Dostęp do baz danych, które rosną w celu zaspokojenia zmieniających się potrzeb, często mają modele danych, które można ulepszyć, patrząc na duży obraz.

Następnie zidentyfikuj moduły aplikacji, które są „samodzielne”. Ponieważ jest to baza danych do zrobienia wszystkiego, prawdopodobnie będą jej moduły, które są prawie całkowicie od siebie oddzielone. Po uzyskaniu tych rozłącznych elementów znajdź jeden z mniejszych modułów, który może najwięcej zyskać na aktualizacji, i weź go jako pierwszy.

Podczas migracji do platformy .NET nie rób prostej kopii aplikacji w formacie 1 do 1. Zbierz dane od użytkowników, aby zidentyfikować punkty bólu w bieżącej aplikacji. Chcesz, aby Twoja pierwsza jednostka migracyjna odniosła ogromny sukces, zdobywając pełne wpisowe od wszystkich innych.

Po ukończeniu pierwszej jednostki, spójrz na to, co się wydarzyło pod względem wyzwań, trudności itp., I skorzystaj z tego, by iść naprzód.

Jedną rzeczą, którą zdecydowanie odradzam, byłoby wdrożenie częściowo działających modułów (np. „Przeprowadziliśmy migrację CRM, ale funkcje X, Y, Z nie są jeszcze w nowym systemie”). Spowoduje to, że użytkownicy szybko odczują frustrację z powodu niepełnego systemu, gdy stary był dla nich „w porządku”. Ten rodzaj rozwoju może działać dobrze w innych domenach, ale nie w firmach, w których użytkownicy widzą „nic złego” w starym monolecie Access i nie rozumieją potrzeb migracji.

Oto rodzaj planu przekształcenia aplikacji MS Access w aplikację VB.Net przez mutację.

To nie jest plan ogólny, następujący plan zależy od opisanego projektu.

Krok 1: migruj wszystkie dane do SQL Server

Nie używaj ODBC do łączenia się z dostępem do SQL Server, zamiast tego użyj Access Project (ADP). Projekt Access to plik Access z rozszerzeniem .adp, ma pełne funkcje dostępu (makra, formularze, raporty, moduły), ale połączenie jest bezpośrednio w bazie danych SQL Server zamiast pliku MDB. Pliki ADP są bardzo kompatybilne z plikami MDB. Wygląda na to, że nie są obsługiwane w programie Access 2010, podczas gdy w rzeczywistości funkcja jest ukryta, ale jest bardzo dobrze obsługiwana. Podobnie jak MDE, pliki ADP można „kompilować” w pliki ADE.

Migracja do SQL Server będzie kosztować niewiele modyfikacji w strukturze danych i kodzie, ale migracja jest dość łatwa. I w końcu jest to ostateczny cel.

Zapomnij o wyzwalaniu zdarzeń bazy danych w kodzie VBA lub VB.Net. Technicznie można to zrobić za pomocą rozszerzonych procedur przechowywanych programu SQL Server, ale jest to bardzo zła sztuczka. Twój projekt ma przyszłość, dlatego lepiej jest egzekwować strukturę danych, unikając tego rodzaju mostu destrukcyjnego. Ogólnie rzecz biorąc, pomijaj wyzwalacze bazy danych, jest inteligentny, ale dość trudny w utrzymaniu.

Krok 2: ujednolicenie uwierzytelnienia

Dobrze, że twoja aplikacja nie opiera się na zabezpieczeniach Access (plik MDW).

Zaplanuj uwierzytelnianie docelowe dla aplikacji VB.Net, a następnie określ sposób migracji uwierzytelnienia Access do tego celu, aby uzyskać jednolite uwierzytelnianie między dwiema aplikacjami.

Ponieważ w architekturze aplikacji uwierzytelnianie odbywa się poprzecznie, łatwiej będzie podzielić między wersją Access na wersję VB.Net.

Krok 3: przygotuj funkcję tokena, aby utworzyć pomost między Access a VB.Net

Powiedziałeś, że Access UI będzie musiał otworzyć VB.Net UI z kilkoma dokładnymi parametrami, a także uwierzytelnieniem. I prawdopodobnie będziesz musiał zrobić to samo w inny sposób.

Dobrym rozwiązaniem jest zbudowanie funkcji małego tokena w oparciu o tablicę tokenów: kolumnami może być identyfikator tokena (liczba całkowita), klucz tokena (długi ciąg), data tokena i lista parametrów (długi ciąg lub tekst). Za każdym razem Access musi otworzyć ekran VB.Net, następnie zapisać token w bazie danych z parametrami, a następnie otworzyć aplikację VB.Net tylko z identyfikatorem tokena i kluczem tokena. Otwiera się VB.Net, wyszukuje identyfikator tokena w bazie danych, sprawdza klucz (dotyczy to uwierzytelnienia) i odczytuje parametry. Następnie otwiera się na odpowiedni formularz i robi to, co jest wymagane. Nie zapomnij podać czasu trwania tokenów i wyczyścić stare tokeny.

Jeśli potrzebujesz oddzwonić z VB.Net do Access (prawdopodobnie będziesz), to myślę, że można aktywować jakiś kod VBA w otwartym pliku MDB Access, używając OLE.

Krok 4: migruj interfejs użytkownika i moduły ekran po ekranie, moduł po module

Teraz wielkie przygotowania są gotowe. Możesz rozpocząć migrację interfejsu użytkownika z Ms Access do VB.Net.

Nie ma dobrych automatycznych narzędzi do tego. VBA i .Net są zbyt różne. Musisz przygotować swoją pracę do takiej migracji. Zacznij od małego formularza, takiego jak pole „Informacje”, i przejdź od prostych formularzy do skomplikowanych formularzy. Oczywiście będziesz musiał powiązać i zaplanować niektóre migracje, ale stopniowo będziesz migrować swoje ekrany, raporty i biblioteki z Ms Access do VB.Net.

Dziwi mnie, że to wszystko zrobiłeś z Access. Jest bardzo ważne pytanie, którego nie zadajesz .NET Windows Forms lub .NET WPF. WPF ma bardziej stromy przebieg uczenia się, ale moim zdaniem jest bardziej wydajny z lepszym interfejsem użytkownika. Niedawno przekonwertowaliśmy naszą aplikację komercyjną z formularzy na WPF i już osiągamy większą sprzedaż. Dodaliśmy również nowe funkcje, ale interfejs użytkownika WPF jest po prostu bardziej seksowny. Sprawdź projekt stołu i posprzątaj go - teraz jest czas. Upewnij się, że deklarujesz wszystkie swoje FK. W programie Access możesz łatwo dodawać rzeczy w locie, czasem te rzeczy się zsuwają. Jeśli jest to twój pierwszy interfejs użytkownika WPF, zbuduj prototypy. Możemy dodać więcej do WPF, że nowa aplikacja ma więcej funkcji, mniej ekranów i mniej dużo kodu. Przejdziesz od nienawiści do XAML do tego, jak go kochasz. Rozważ strukturę taką jak MVVM.

Ponieważ masz już dobrą znajomość modelu obiektowego Access, myślę, że chcesz użyć Access Interop z aplikacji .NET. Powinno (mniej więcej) pozwolić ci zautomatyzować kontrolę nad aplikacją Access, bez nieprzejrzystości DDE.

Nie znam głębokiej wiedzy na temat Twojej warstwy logiki biznesowej, ale możesz również uzyskać dostęp do baz danych MS Access w aplikacji .NET. Jeśli nie chodzi tylko o pobieranie danych, możesz zaimplementować połączenie TCP / IP między swoimi programami (aplikacjami VB6 i VB.NET). Proszę rzucić okiem na artykuł na CodeProject .

Prosisz o najlepszą praktykę, jak zrobić coś złego. Nie ma jednego Najlepsze praktyki obejmują to, jak skutecznie stworzyć utrzymywalny system, aby nawet w przypadku awarii autobusu i pojawienia się zupełnie nowego zespołu, rozwój i wsparcie mogły być kontynuowane. System, który opisujesz, wyśle ​​większość programistów ubiegających się o wzgórza. Masz produkt zbudowany z przestarzałej technologii i chcesz połączyć się z dzisiejszą technologią. I chcesz to zrobić bez adresowania któregokolwiek z anty-wzorów, które opisałeś dla podstawowego produktu. Programiści, którzy zechcą się z tym zmierzyć, prawdopodobnie nie będą chcieli tego zrobić w proponowanych przez ciebie warunkach.

Jednak autobus się nie rozbił, więc możesz wykorzystać istniejący zespół, który rozumie system. Najlepszym sposobem na stopniowy rozwój, jaki znalazłem, jest zastosowanie metodyki zwinnej. Obsługuje iteracyjny proces, który wcześnie spełnia wymagania wysokiego ryzyka i dobrze zaspokaja potrzeby biznesowe.

Postanowiliśmy stopniowo przenieść naszą aplikację w kierunku .Net

Często pomyłka. Najlepszą praktyką jest nie próbować „stopniowo”.

mimo że jest to nowy język dla większości programistów tutaj, mamy głęboką znajomość VBA i kilkudziesięciu małych projektów wdrożonych w VB6.

Niezbyt dobra podstawa do podjęcia decyzji. Jeśli chcesz nauczyć się nowego języka, nie ucz się VB. Naucz się C # lub czegoś jeszcze lepszego jak Java.

„nowy język dla większości programistów tutaj, mamy dogłębną znajomość VBA” to powszechne wyrażenie kodowe dla „mamy Guru VBA, którego nie chcemy drażnić”. To też może być coś złego.

To, czego szukamy, to najlepsze praktyki dotyczące stopniowego przenoszenia naszego rozbudowanego interfejsu GUI

Najlepsze praktyki nie obejmują „stopniowego”. Obejmują one „Odrzuć całkowicie”.

Stopniowe migracje, które widziałem, załamały się, ponieważ są tak trudne.

Lepiej to rób.

1. Zachowaj najcenniejszy zasób . Dane. Przenieś wszystkie dane do SQL Server. Wszystko. Przepisz wszystkie MS-Access, aby korzystać z połączeń ODBC z programem SQL Server. Teraz.

2. Zwolnij każdego, kto tworzy tymczasowe tabele lub dane lub cokolwiek innego w MS-Access. Wszystkie dane muszą znajdować się w bazie danych poza MS-Access. Dane w MS-Access są przyczyną problemów, więc zatrzymaj się teraz i upewnij się, że wszyscy się zgadzają. Jeśli się nie zgadzają, znajdź im nową pracę, która nie wymaga hakowania w MS-Access, gdy próbujesz pozbyć się MS-Access.

3. Znajdź strukturę raportowania, która automatycznie generuje raporty zbliżone do tego, co masz teraz. Bez programowania. Po prostu daj mu stolik lub widok i wybuchaj! zrobione.

4. Zliczyć wszystkie 500 raportów. Podziel je na raporty, które można łatwo zbudować za pomocą narzędzia, i raporty, które są trudniejsze. Priorytetowe dla twardych należy ustawić na „Must Have”, „Have Have”, Could Have ”i„ Won't Do Until Later ”. Zastąp zautomatyzowane raporty i raporty obowiązkowe tym narzędziem do raportowania całkowicie poza MS-Access.

   Z mojego doświadczenia wynika, że ​​widok bazy danych często jest ponownie wykorzystywany w około 20 raportach. Z tego sądzę, że masz 25 odpowiednich widoków, z których wywodzi się 500 raportów. Każde narzędzie, które może zautomatyzować tworzenie raportów, powinno obsłużyć większość raportów z małego zestawu dobrze spreparowanych widoków SQL. Kilka raportów będzie zbyt skomplikowanych lub trudnych dla automatycznego narzędzia.

5. Znajdź platformę programistyczną, która automatycznie buduje transakcje CRUD.

6. Podziel 200 formularzy na części na formularze CRUD (które można budować automatycznie) i formularze inne niż CRUD. Spośród innych niż CRUD ustal priorytety przy użyciu reguł MoSCoW (Must, Should, Could, Won't).

   Często 60–80% formularzy wniosków to proste, zautomatyzowane formularze CRUD. 20–40% jest bardziej złożonych i wymaga bardziej wykwalifikowanego programowania. Na tej podstawie masz od 120 do 160 formularzy CRUD, których nie musisz przepisywać, wystarczy zautomatyzować. Masz 40–80 poważnie skomplikowanych transakcji.

7. Zbuduj formularze CRUD i formularze Must-have non-CRUD.

8. Oceń luki. Ponownie ustal priorytety i zacznij pracę nad najważniejszymi częściami listy „Warto mieć”.

Prawdopodobnie najłatwiej jest całkowicie odrzucić Access. Unikaj stopniowości.

W końcu wydasz wszystkie pieniądze.

Równie dobrze możesz przeznaczyć na to budżet i wydać go teraz.

Próbując to zrobić stopniowo może faktycznie być bardziej kosztowne ze względu na złożoność próbuje zarządzać współistnienia.