Thực tiễn tốt nhất để di chuyển ứng dụng MS Access lớn sang .Net?

Chúng tôi có một ứng dụng MS Access thực sự khổng lồ được phát triển nội bộ ban đầu cho nhu cầu cá nhân của chúng tôi sau đó được chuyển thành phần mềm thương mại và được bán thành công. Phần mềm này là một loại "phần mềm toàn diện cho doanh nghiệp của bạn" và chứa một số mô-đun bao gồm Hệ thống quản lý tài liệu, Lập kế hoạch tài nguyên doanh nghiệp, Quản lý kho, Quản lý quan hệ khách hàng, Phân tích dữ liệu, v.v. Chúng tôi khá hài lòng với hiện tại chức năng của ứng dụng, nhưng để đáp ứng các yêu cầu từ khách hàng, chúng tôi nhận ra rằng chúng tôi phải chuyển sang một thứ mới.

Chúng tôi quyết định dần dần chuyển ứng dụng của mình sang .Net vì chúng tôi có thể gắn bó với Visual Basic .Net: mặc dù đó là ngôn ngữ mới cho hầu hết các nhà phát triển ở đây, chúng tôi có kiến ​​thức sâu về VBA và hàng tá dự án nhỏ được triển khai trong VB6.

Chúng tôi đã bắt đầu chuyển chức năng lớp dữ liệu của ứng dụng của mình sang MS SQL Server, để mọi thao tác và tìm kiếm dữ liệu được thực hiện trực tiếp trên máy chủ.

Những gì chúng tôi đang tìm kiếm là các thực tiễn tốt nhất để chuyển dần GUI rộng lớn của chúng tôi (khoảng 500-600 hình thức khác nhau bao gồm biểu mẫu con, khoảng 200 báo cáo có hỗ trợ đa ngôn ngữ, v.v.). Theo yêu cầu gần đây từ khách hàng tiềm năng của chúng tôi để thực hiện mã hóa dữ liệu không đồng bộ trên các tài liệu trong DMS, chúng tôi cũng rất vui khi tách hoàn toàn phần này khỏi MS Access và triển khai nó trong .Net.

Câu hỏi đặt ra là làm thế nào để tích hợp liền mạch ứng dụng .Net với hệ thống MS Access hiện có, để chúng tôi có thể gọi nó với một số tham số nhất định (quyền người dùng, v.v.) và cho phép trao đổi dữ liệu giữa ứng dụng này và chạy ứng dụng MS Access.

CHỈNH SỬA:

Chúng tôi đã cố gắng áp dụng một số thực tiễn từ cuốn sách " Các mẫu kết hợp doanh nghiệp " của Martin Fowler để đạt được một số tích hợp giữa ứng dụng MS Access và một số tiện ích nhỏ mà chúng tôi đã triển khai trong .Net cho các nhu cầu khác nhau. Nhưng chúng tôi chỉ quản lý để sử dụng mẫu "cơ sở dữ liệu dùng chung" và không thực sự hài lòng với giải pháp của chúng tôi.

Chẳng hạn, chúng tôi đã triển khai một tiện ích nhỏ chạy dưới dạng dịch vụ Windows, tự động tải xuống tất cả thư từ máy chủ thư bằng kết nối POP3 và lưu trữ chúng vào một bảng, trong khi tất cả các tệp đính kèm được lưu trữ trong hệ thống tệp.

Những gì chúng tôi chủ yếu làm là chúng tôi đã sử dụng ADO.NET để truy cập trực tiếp vào cơ sở dữ liệu MS Access ở định dạng MDB và điền vào bảng một số dữ liệu đã xử lý (như dữ liệu về thư trong ví dụ ở trên: chúng tôi có các trường cho TỪ, TO, CC, BCC, Chủ thể và cơ thể).

Hoàn toàn không có vấn đề gì khi làm việc với định dạng dữ liệu MDB từ .Net , hơn nữa chúng tôi không muốn ở lại với MDB và tăng kích thước gần như mọi thứ cho MS SQL Server 2008 - điều này cho chúng tôi nhiều tự do hơn về quản lý dữ liệu và khả năng mở rộng.

Vấn đề chính ở đây là chúng tôi không biết cách triển khai một loại "gọi lại" trong Access để có thể kích hoạt việc thực thi mã VBA nhất định trên cập nhật dữ liệu.

Chúng tôi rất hy vọng với MS Access 2010 hỗ trợ cập nhật và chèn trình kích hoạt cho các bảng dữ liệu , nhưng hóa ra chúng tôi chỉ có thể sử dụng MS Access Macros cho các trình kích hoạt này và không có cách nào để thực thi bất kỳ mã VBA tùy chỉnh nào trong trình kích hoạt.

Chúng tôi cũng đã thử một số giải pháp bằng cách gửi tổ hợp phím trực tiếp đến cửa sổ MS Access để bắt chước một số yêu cầu dữ liệu do người dùng yêu cầu. Điều này hoạt động, nhưng chúng tôi không nghĩ rằng đây là một giải pháp khả thi có thể được sử dụng trong sản xuất.

Chúng tôi cũng đã xem xét DDE cho MS Access, nhưng chúng tôi không thể tìm thấy bất kỳ giải pháp mẫu tốt nào thực hiện các lệnh DDE và sử dụng chúng cho dữ liệu trong bộ nhớ và trao đổi lệnh.

Vì vậy, vấn đề chính là để ứng dụng MS Access và .Net cùng tồn tại và tương tác với nhau.

EDIT2 :

Tôi đã quên đề cập đến những gì chúng tôi cũng đã triển khai thư viện MSMQ trong VBA cho tin nhắn chuyển qua .Net và MS Access, vấn đề một lần nữa là thiếu cuộc gọi lại ở đây: chúng tôi thực sự phải thăm dò hàng đợi cho các tin nhắn mới và cho rằng VBA không thực sự hỗ trợ đa luồng nó không thực sự là một giải pháp tốt.

Đây sẽ là một dự án lớn và rất liên quan. Tôi đã chịu trách nhiệm di chuyển cơ sở dữ liệu Access sang .NET nhiều lần, nhưng không bao giờ ở quy mô này. Tôi đồng ý rằng một cách tiếp cận dần dần có thể sẽ là thực tế nhất. Cố gắng đảm nhận mọi thứ trong một lần bắn là một cách dễ dàng để thất bại.

Như trong các câu trả lời khác, bước đầu tiên và quan trọng nhất sẽ là chuyển mọi thứ sang SQL Server. Trong khi thực hiện việc này, hãy ghi lại cơ sở dữ liệu nếu việc này chưa được thực hiện và xác định các khu vực để tái cấu trúc nếu chúng tồn tại. Truy cập cơ sở dữ liệu phát triển để đáp ứng nhu cầu phát triển thường có các mô hình dữ liệu có thể được cải thiện khi nhìn vào bức tranh lớn.

Tiếp theo, xác định các mô-đun của ứng dụng "khép kín". Bởi vì đây là cơ sở dữ liệu do-mọi thứ, nên có thể sẽ có các mô-đun của nó gần như hoàn toàn tách rời nhau. Sau khi có các phần rời rạc này, hãy xác định một trong các mô-đun nhỏ hơn có nhiều nhất để đạt được từ việc cập nhật và đưa nó vào trước.

Trong khi di chuyển sang .NET, đừng chỉ thực hiện một bản sao đơn giản từ 1 đến 1 của ứng dụng. Thu thập đầu vào từ người dùng để xác định các điểm đau với ứng dụng hiện tại. Bạn muốn đơn vị di chuyển đầu tiên của mình thành công lớn để có được sự mua hoàn toàn từ những người khác.

Sau khi bạn hoàn thành đơn vị đầu tiên, hãy xem những gì đã xảy ra về mặt thách thức, khó khăn, v.v. và sử dụng bước tiến này.

Một điều mà tôi rất khuyến khích là triển khai các mô đun hoạt động một phần (ví dụ: "chúng tôi đã di chuyển CRM, nhưng các tính năng X, Y, Z chưa có trong hệ thống mới"). Điều này sẽ khiến người dùng nhanh chóng trở nên thất vọng vì có một hệ thống chưa hoàn chỉnh khi hệ thống cũ đối với họ "hoàn toàn ổn". Kiểu phát triển này có thể hoạt động tốt đối với các miền khác, nhưng không phải ở các doanh nghiệp nơi người dùng thấy "không có gì sai" với khối nguyên khối Access cũ và không hiểu nhu cầu di chuyển.

Đây là một loại kế hoạch để biến ứng dụng MS Access của bạn thành ứng dụng VB.Net do đột biến.

Đây không phải là một kế hoạch chung, kế hoạch sau đây phụ thuộc vào dự án bạn đã mô tả.

Bước 1: di chuyển tất cả dữ liệu sang SQL Server

Không sử dụng ODBC để kết nối Truy cập vào SQL Server, thay vào đó hãy sử dụng Dự án truy cập (ADP). Access Project là một tệp Access có phần mở rộng .adp, nó có đầy đủ các tính năng Access (Macros, Forms, Báo cáo, Mô-đun) nhưng kết nối trực tiếp trên cơ sở dữ liệu SQL Server thay vì tệp MDB. Các tệp ADP rất tương thích với các tệp MDB. Chúng dường như không được hỗ trợ trong Access 2010, trong khi thực tế tính năng này bị ẩn nhưng nó được hỗ trợ rất tốt. Giống như MDE, các tệp ADP có thể được "biên dịch" thành các tệp ADE.

Di chuyển vào SQL Server sẽ tốn một vài sửa đổi trong cấu trúc dữ liệu và mã, nhưng tất cả đều khá dễ dàng để di chuyển. Và nó là một mục tiêu cuối cùng sau tất cả.

Hãy quên việc kích hoạt các sự kiện cơ sở dữ liệu sang mã VBA hoặc VB.Net. Điều này về mặt kỹ thuật có thể được thực hiện bằng cách sử dụng các thủ tục lưu trữ mở rộng của SQL Server, nhưng là một thủ thuật rất xấu. Dự án của bạn có một cuộc sống trong tương lai, vì vậy tốt hơn là thực thi cấu trúc Dữ liệu của nó bằng cách tránh loại cầu phá hủy như vậy. Nói chung, chơi với các kích hoạt cơ sở dữ liệu, nó thông minh nhưng khá khó để duy trì.

Bước 2: làm đồng phục xác thực

Một điều tốt là ứng dụng của bạn không dựa trên bảo mật Access (tệp MDW).

Lập kế hoạch xác thực mục tiêu cho ứng dụng VB.Net và sau đó xác định cách di chuyển xác thực Access sang mục tiêu này để có xác thực thống nhất giữa hai ứng dụng.

Do xác thực là ngang trong kiến ​​trúc ứng dụng, nên việc cắt giữa phiên bản Access sang phiên bản VB.Net sẽ dễ dàng hơn.

Bước 3: chuẩn bị tính năng mã thông báo để tạo cầu nối giữa Access và VB.Net

Bạn đã nói, UI truy cập sẽ phải mở UI VB.Net với một số tham số chính xác và xác thực. Và có lẽ bạn sẽ phải làm điều tương tự theo cách khác.

Một giải pháp tốt là xây dựng một tính năng mã thông báo nhỏ dựa trên bảng mã thông báo: các cột có thể là mã thông báo (số nguyên), khóa mã thông báo (chuỗi dài), ngày mã thông báo và danh sách tham số (chuỗi dài hoặc văn bản). Mỗi lần Access cần mở màn hình VB.Net, sau đó lưu mã thông báo trong cơ sở dữ liệu với các tham số, sau đó mở ứng dụng VB.Net của bạn chỉ bằng id mã thông báo và khóa mã thông báo. VB.Net mở, tìm kiếm id mã thông báo trong cơ sở dữ liệu, kiểm tra khóa (điều này áp dụng như một xác thực) và đọc các tham số. Sau đó, nó mở ra hình thức tương ứng, và làm những gì được yêu cầu. Đừng quên cung cấp thời lượng cho mã thông báo và dọn sạch mã thông báo cũ.

Nếu bạn cần gọi lại từ VB.Net sang Access (có thể bạn sẽ làm vậy), thì tôi nghĩ có thể kích hoạt một số mã VBA trên tệp Truy cập MDB đã mở, sử dụng OLE.

Bước 4: di chuyển màn hình UI và Modules theo màn hình, mô-đun theo mô-đun

Bây giờ việc chuẩn bị lớn đã xong. Bạn có thể bắt đầu di chuyển giao diện người dùng từ Ms Access sang VB.Net.

Không có công cụ tự động tốt để làm điều này. VBA và .Net quá khác nhau. Bạn phải chuẩn bị công việc của bạn cho một cuộc di cư như vậy. Bắt đầu với một hình thức nhỏ, như hộp "Giới thiệu" và tiếp tục từ các hình thức đơn giản đến các hình thức phức tạp. Tất nhiên bạn sẽ phải bó và lên lịch một số lần di chuyển, nhưng bạn sẽ dần dần di chuyển màn hình, báo cáo và thư viện của mình từ Ms Access sang VB.Net.

Tôi ngạc nhiên khi bạn đã làm tất cả điều đó với Access. Có một câu hỏi rất quan trọng bạn không hỏi .NET Windows Forms hoặc .NET WPF. WPF có một đường cong học tập dốc hơn nhưng theo tôi nó mạnh hơn với giao diện người dùng tốt hơn. Gần đây chúng tôi đã chuyển đổi ứng dụng thương mại của mình từ Forms sang WPF và chúng tôi đã nhận được nhiều doanh số hơn. Chúng tôi cũng đã thêm các tính năng mới nhưng giao diện người dùng WPF chỉ hấp dẫn hơn. Xem lại thiết kế bảng của bạn và dọn dẹp nó - bây giờ là thời gian. Hãy chắc chắn rằng bạn đang khai báo tất cả các FK của bạn. Trong Access, bạn có thể thêm nội dung một cách dễ dàng một số lần mà công cụ bị trượt. Nếu đây là UI WPF đầu tiên của bạn xây dựng một số nguyên mẫu. Chúng tôi có thể đóng gói nhiều hơn vào WPF rằng ứng dụng mới có nhiều tính năng hơn, ít màn hình hơn và ít mã hơn rất nhiều. Bạn sẽ đi từ ghét XAML đến việc yêu nó như thế nào. Hãy xem xét một cấu trúc như MVVM.

Vì bạn đã hiểu rõ về mô hình đối tượng Access, tôi sẽ nghĩ rằng bạn muốn sử dụng Access Interop từ ứng dụng .NET của mình. Nó sẽ (nhiều hơn hoặc ít hơn) cho phép bạn tự động hóa quyền kiểm soát ứng dụng Access, mà không có sự mờ nhạt của DDE.

Tôi không biết kiến ​​thức sâu về lớp logic kinh doanh của bạn, nhưng bạn cũng có thể truy cập cơ sở dữ liệu MS Access trong ứng dụng .NET của mình. Nếu không chỉ đơn giản là tìm nạp dữ liệu, bạn có thể triển khai kết nối TCP / IP giữa các chương trình của mình (ứng dụng VB6 và VB.NET). Xin hãy xem một bài viết về CodeProject .

Bạn đang yêu cầu thực hành tốt nhất về cách làm sai. Không có một. Thực tiễn tốt nhất bao gồm cách tạo ra một hệ thống có thể bảo trì một cách hiệu quả, để ngay cả khi xe buýt gặp sự cố và một đội hoàn toàn mới cần phải chịu lạnh, sự phát triển và hỗ trợ vẫn có thể tiếp tục. Hệ thống mà bạn mô tả sẽ gửi hầu hết các nhà phát triển chạy cho các ngọn đồi. Bạn có sản phẩm được xây dựng với công nghệ lạc hậu và muốn giao tiếp với công nghệ ngày nay. Và bạn muốn làm như vậy với việc giải quyết bất kỳ mẫu chống bạn đã mô tả cho sản phẩm cốt lõi. Những nhà phát triển sẵn sàng giải quyết nó có thể sẽ không sẵn lòng làm điều đó với các điều kiện bạn đề xuất.

Tuy nhiên, xe buýt của bạn đã không gặp sự cố để bạn có thể tận dụng đội ngũ hiện có hiểu hệ thống. Cách tốt nhất để phát triển dần dần mà tôi đã tìm thấy là sử dụng Phương pháp Agile. Nó hỗ trợ một quy trình lặp để giải quyết sớm các yêu cầu rủi ro cao và giải quyết tốt nhu cầu kinh doanh.

Chúng tôi quyết định dần dần chuyển ứng dụng của chúng tôi sang .Net

Thường là một sai lầm. Thực hành tốt nhất là không thử "dần dần".

mặc dù đó là ngôn ngữ mới cho hầu hết các nhà phát triển ở đây, chúng tôi có kiến ​​thức sâu về VBA và hàng tá dự án nhỏ được triển khai trong VB6.

Không phải là một cơ sở rất tốt cho một quyết định. Nếu bạn muốn học một ngôn ngữ mới, đừng học VB. Tìm hiểu C # hoặc một cái gì đó thậm chí tốt hơn như Java.

"Một ngôn ngữ mới cho hầu hết các nhà phát triển ở đây, chúng tôi có kiến ​​thức sâu về VBA" là cụm từ mã phổ biến cho "chúng tôi có một Chuyên gia VBA mà chúng tôi không muốn gây khó chịu". Đó cũng là điều có thể xấu.

Những gì chúng tôi đang tìm kiếm là các thực tiễn tốt nhất để chuyển dần GUI rộng lớn của chúng tôi

Các thực hành tốt nhất không liên quan đến "Dần dần". Chúng liên quan đến "Hủy bỏ hoàn toàn".

Các cuộc di cư dần dần mà tôi thấy đã bị phá vỡ vì quá khó khăn.

Bạn tốt hơn nên làm điều này.

1. Bảo toàn tài sản quý giá nhất . Dữ liệu. Di chuyển tất cả dữ liệu sang SQL Server. Tất cả. Viết lại tất cả MS-Access để sử dụng các kết nối ODBC đến SQL Server. Ngay bây giờ.

2. Bắn bất cứ ai tạo bảng hoặc dữ liệu tạm thời hoặc bất cứ thứ gì trong MS-Access. Tất cả dữ liệu phải sống trong cơ sở dữ liệu bên ngoài MS-Access. Dữ liệu trong MS-Access là nguyên nhân gây ra sự cố, vì vậy hãy dừng ngay bây giờ và chắc chắn rằng mọi người đều đồng ý. Nếu họ không đồng ý, hãy tìm cho họ một công việc mới không liên quan đến hack MS-Access trong khi bạn đang cố gắng thoát khỏi MS-Access.

3. Tìm một khung báo cáo sẽ tự động tạo các báo cáo gần với những gì bạn có bây giờ. Không có lập trình. Chỉ cần cho nó một cái bàn hoặc một cái nhìn và đập! xong rôi.

4. Liệt kê tất cả 500 báo cáo. Phân vùng chúng thành các báo cáo được xây dựng dễ dàng với công cụ và các báo cáo khó hơn. Ưu tiên những cái khó thành "Phải có", "Nên có", có thể có "và" Sẽ không làm cho đến sau này ". Thay thế các báo cáo tự động và công cụ báo cáo phải có này hoàn toàn bên ngoài MS-Access.

   Kinh nghiệm của tôi là chế độ xem cơ sở dữ liệu thường được sử dụng lại trong khoảng 20 báo cáo. Từ đó, tôi đoán rằng bạn có 25 lượt xem có liên quan từ đó 500 báo cáo được lấy. Bất kỳ công cụ nào có thể tự động hóa sản xuất báo cáo sẽ xử lý hầu hết báo cáo của bạn từ một nhóm nhỏ các chế độ xem SQL được xây dựng tốt. Một vài báo cáo sẽ quá phức tạp hoặc khó khăn đối với một công cụ tự động.

5. Tìm một khung phát triển xây dựng các giao dịch CRUD tự động.

6. Phân vùng 200 biểu mẫu của bạn thành các biểu mẫu CRUD (có thể được xây dựng tự động) và các biểu mẫu không CRUD. Trong số những người không CRUD, hãy ưu tiên sử dụng các quy tắc MoSCoW (Phải, Nên, Có thể, Không).

   Thông thường, 60-80% mẫu đơn ứng dụng là mẫu CRUD đơn giản, tự động. 20-40% phức tạp hơn và đòi hỏi lập trình thành thạo hơn. Dựa trên điều này, bạn có 120 đến 160 mẫu CRUD mà bạn không cần phải viết lại, chỉ cần tự động hóa. Bạn có 40-80 giao dịch phức tạp nghiêm trọng.

7. Xây dựng các hình thức CRUD và các hình thức Không phải CRUD.

8. Đánh giá các khoảng trống. Ưu tiên lại và bắt đầu làm việc trên các phần quan trọng nhất của danh sách "Nên có".

Có lẽ dễ dàng nhất để loại bỏ quyền truy cập hoàn toàn. Tránh dần dần.

Cuối cùng bạn sẽ tiêu hết tiền.

Bạn cũng có thể ngân sách cho nó và chi tiêu ngay bây giờ.

Đang cố gắng để làm điều này dần dần có thể thực sự được nhiều tốn kém vì sự phức tạp của cố gắng để quản lý chung sống.