Büyük MS Access uygulamasını .Net'e doğru taşımak için en iyi yöntemler?

Daha önce ticari bir yazılıma dönüştürülen ve başarılı bir şekilde satılan kişisel ihtiyaçlarımız için şirket içinde geliştirilen çok büyük bir MS Access uygulamasına sahibiz. Yazılım, "işiniz için çok yönlü bir yazılım" türüdür ve Doküman Yönetim Sistemi, Kurumsal Kaynak Planlama, Envanter Yönetimi, Müşteri İlişkileri Yönetimi, Veri Analizi vb. Gibi çeşitli modüller içerir. Mevcut durumdan oldukça memnunuz. Uygulamanın işlevselliği, ancak müşterilerimizin isteklerini karşılamak için yeni bir şeye geçmemiz gerektiğinin farkındayız.

Uygulamamızı aşamalı olarak .Net'e taşımaya karar verdik çünkü Visual Basic. Net'e bağlı kalabiliyoruz: buradaki geliştiricilerin çoğu için yeni bir dil olmasına rağmen, VBA ve VB6'da uygulanan birkaç düzine küçük proje hakkında derin bilgiye sahibiz.

Uygulamamızın veri katmanı işlevselliğini MS SQL Server'a taşımaya başladık, böylece her veri manipülasyonu ve arama doğrudan sunucu üzerinde gerçekleştirildi.

Aradığımız şey, geniş GUI'lerimizi kademeli olarak hareket ettirmek için en iyi uygulamalardır (alt formlar dahil yaklaşık 500-600 farklı form, çok dilli desteğe sahip yaklaşık 200 rapor vb.). Potansiyel müşterimizden DMS'deki belgelere zaman uyumsuz veri şifrelemesi uygulama talebinin ardından, bu parçayı MS Access'ten tamamen ayırıp .Net'te uygulamaktan memnuniyet duyarız.

Sorun, .NET uygulamasını mevcut MS Access sistemi ile nasıl sorunsuz bir şekilde bütünleştireceğimizdir, böylece onu belirli parametrelerle (kullanıcı hakları vb.) Çağırabilir ve bu uygulama ile MS Access uygulamasını çalıştıran arasında veri alışverişini sağlayabiliriz.

DÜZENLE:

MS Access uygulaması ile çeşitli ihtiyaçlar için .Net'te uyguladığımız küçük yardımcı programlar arasında entegrasyon sağlamak için Martin Fowler'in " Kurumsal entegrasyon kalıpları " kitabından bazı uygulamaları uygulamaya çalıştık . Ancak yalnızca "paylaşılan veritabanı" modelini kullanmayı başardık ve çözümümüzden gerçekten memnun kalmadık.

Örneğin, Windows hizmeti olarak çalışan ve POP3 bağlantısını kullanarak tüm mesajları posta sunucusundan otomatik olarak indiren ve bunları tek bir tabloda saklayan küçük bir yardımcı program uyguladık, oysa tüm ekler dosya sisteminde saklandı.

Temelde yaptığımız şey, ADO.NET'i MDB formatında MS Access veritabanlarına doğrudan erişmek ve tabloyu bazı işlenmiş verilerle doldurmak (yukarıdaki örnekten gelen posta mesajları hakkındaki veriler gibi: FROM, TO, CC, BCC, Konu ve Beden).

Net'ten MDB veri formatıyla çalışmak kesinlikle bir sorun değil, ayrıca MDB ile kalmak istemiyoruz ve MS SQL Server 2008'e neredeyse her şeyi yükseltmek istemiyoruz - bu bize veri yönetimi ve ölçeklenebilirlik konusunda daha fazla özgürlük sunuyor.

Buradaki asıl sorun , Access'te bir çeşit "geri arama" nın nasıl uygulanacağını bilmememizdir , böylece veri güncellemesinde belirli VBA kodlarının yürütülmesini tetikleyebiliriz.

MS Access 2010 ile veri tabanları için güncelleme ve ekleme tetikleyicilerini destekleyen büyük umutlarımız vardı , ancak bu tetikleyiciler için yalnızca MS Access Makrolarını kullanabileceğimiz ve tetikleyicide herhangi bir özel VBA kodu yürütmenin mümkün olmadığı ortaya çıktı.

Ayrıca bazı kullanıcı tarafından çağrılan veri gereksinimlerini taklit etmek için tuş vuruşlarını doğrudan MS Access penceresine göndermekle de bazı çözümler denedik . Bu işe yarıyor ama bunun üretimde kullanılabilecek makul bir çözüm olduğunu düşünmüyoruz.

MS Access için DDE'yi de inceledik, ancak DDE komutlarını uygulayan ve bunları bellek içi veri ve komut değişimi için kullanan herhangi bir iyi örnek çözüm bulamadık .

Bu nedenle, asıl sorun MS Access ve. Net uygulamasının birlikte var olması ve birbirleriyle etkileşime geçmesidir.

EDIT2 :

Net ve MS Access arasındaki iletiler için VBA'da MSMQ kitaplığını da uyguladığımızdan bahsetmeyi unuttum , sorun yine buradaki geri aramaların olmamasıydı: yeni iletiler için kuyruğu sorgulamak zorunda kaldık ve VBA'nın gerçekten desteklemediği göz önüne alındığında çoklu iş parçacığı gerçekten güzel bir çözüm değildi.

Bu büyük ve çok ilgili bir proje olacak. Access veritabanlarını .NET'e birçok kez aktarmaktan sorumlu oldum, ancak bu ölçekte asla. Aşamalı bir yaklaşımın muhtemelen en gerçekçi olacağına katılıyorum. Tek çekimde her şeyi almaya çalışmak başarısızlığın kolay bir yoludur.

Diğer cevaplarda olduğu gibi, ilk ve en önemli adım her şeyi SQL Server'a taşımak olacaktır. Bunu yaparken, daha önce yapılmadıysa veritabanını belgeleyin ve varsa yeniden düzenleme için alanları belirleyin. Gelişen ihtiyaçları karşılamak için büyüyen erişim veritabanlarına sıklıkla büyük resme bakıldığında geliştirilebilecek veri modelleri vardır.

Sonra, uygulamanın "kendi kendine yeten" modülleri tanımlayın. Bu her şeyi yapan bir veritabanı olduğu için muhtemelen birbirinden tamamen ayrı olan modülleri olacaktır. Bu ayrık parçaları bir araya getirdikten sonra, güncellenmekten en fazla kazanacak olan küçük modüllerden birini belirleyin ve ilk önce onu alın.

.NET'e geçiş yaparken, uygulamanın basit bir 1-1 kopyasını yapmayın. Mevcut uygulama ile ağrı noktalarını tanımlamak için kullanıcılardan girdi toplayın. İlk göç ünitenizin, herkesten tam bir satın alma elde etmek için büyük bir başarı olmasını istiyorsunuz.

İlk üniteyi yaptıktan sonra, zorluklar, zorluklar, vs. açısından neler olduğuna bakın ve bu ilerlemeyi kullanın.

Kesinlikle cesaret kırıcı olacağım bir şey, kısmen çalışan modüller uygulamak olacaktır (örneğin: "CRM'i taşıdık ama X, Y, Z özellikleri henüz yeni sistemde değil"). Bu, kullanıcıların eskisi "mükemmel şekilde iyi" olduğunda, tamamlanmamış bir sisteme sahip olmalarından hızlı bir şekilde hayal kırıklığına uğramasına neden olacaktır. Bu tür bir gelişme, diğer alanlar için iyi sonuç verebilir, ancak kullanıcıların eski Access monolith'lerinde "yanlış bir şey" görmeyen ve göç ihtiyaçlarını anlamayan işletmelerde çalışmayabilir.

MS Access uygulamanızı mutasyonla bir VB.Net uygulamasına dönüştürmek için kullanabileceğiniz bir plan.

Bu genel bir plan değildir, aşağıdaki plan tanımladığınız projeye bağlıdır.

1. Adım: tüm verileri SQL Server'a taşıma

ODBC'yi SQL Server'a erişmek için bağlantı olarak kullanmayın, bunun yerine bir Access Project (ADP) kullanın. Bir Access Projesi .adp uzantılı bir Access dosyasıdır, tam Erişim özelliklerine sahiptir (Makrolar, Formlar, Raporlar, Modüller) ancak bağlantı doğrudan MDB dosyası yerine bir SQL Server veritabanındadır. ADP dosyaları MDB dosyalarıyla çok uyumludur. Access 2010'da desteklenmiyor gibi gözüküyorlar, aslında bu özellik gizlenmiş ancak destekleniyor. MDE gibi, ADP dosyaları da ADE dosyalarına "derlenebilir".

SQL Server'a geçmek, veri yapısı ve kodunda birkaç değişikliğe mal olur, ancak bunların taşınması oldukça kolaydır. Ve sonuçta bu nihai bir hedef.

Veritabanı olaylarını VBA veya VB.Net koduna tetiklemeyi unutun. Bu teknik olarak SQL Server Genişletilmiş Saklı Prosedürleri kullanılarak yapılabilir, ancak çok kötü bir hiledir. Projeniz gelecekteki bir ömre sahip olduğundan, bu tür bir yıkıcı köprüden kaçınarak Veri yapısını uygulamak daha iyidir. Genel olarak, veritabanı tetikleyicileri ile oynayın, akıllıdır ancak bakımı oldukça zordur.

2. Adım: kimlik doğrulamayı tek tip yapın

Uygulamanızın Access güvenliğine (MDW dosyası) dayanmaması iyi bir şeydir.

VB.Net uygulaması için hedef kimlik doğrulaması için bir plan yapın ve sonra iki uygulama arasında tek tip bir kimlik doğrulaması yapmak için Erişim kimlik doğrulamasını bu hedefe geçirmenin bir yolunu tanımlayın.

Kimlik doğrulama bir uygulama mimarisinde enine olduğundan, Access sürümü ile VB.Net sürümü arasında geçiş yapmak daha kolay olacaktır.

Adım 3: Access ve VB.Net arasında köprü oluşturmak için bir belirteç özelliği hazırlayın.

Access UI’nin, VB.Net kullanıcı arayüzünü bazı doğru parametrelerle ve aynı zamanda kimlik doğrulamasıyla açması gerektiğini söylediniz. Muhtemelen aynısını başka şekilde de yapman gerekecek.

Bir simge tablosuna dayanan küçük bir simge özelliği oluşturmak iyi bir çözümdür: sütunlar bir simge kimliği (tam sayı), bir simge anahtarı (uzun dize), bir simge tarihi ve bir parametre listesi (uzun dize veya metin) olabilir. Access'in bir VB.Net ekranı açması, ardından parametreleri içeren veritabanında bir jetonu kaydetmesi ve VB.Net uygulamanızı yalnızca simge kimliği ve simge anahtarıyla açması gerekir. VB.Net açılır, belirteç kimliğini veritabanında arar, anahtarı kontrol eder (bu bir kimlik doğrulama olarak uygulanır) ve parametreleri okur. Sonra karşılık gelen forma açılır ve gerekenleri yapın. Jetonlara zaman vermeyi ve eski jetonları temizlemeyi unutmayın.

VB.Net'ten Access'e geri arama yapmanız gerekiyorsa (muhtemelen kullanacaksınız), o zaman açık bir MDB Access dosyasında OLE kullanarak bazı VBA kodlarını etkinleştirmenin mümkün olduğunu düşünüyorum.

Adım 4: Kullanıcı Arabirimi ve Modüller ekranını ekrana, modül modüle geçirin

Şimdi hazırlamanın büyük kısmı bitti. Ms Access'ten VB.Net'e kullanıcı arayüzünü taşımaya başlayabilirsiniz.

Bunu yapmak için iyi bir otomatik araç yoktur. VBA ve .Net çok farklı. Çalışmanızı böyle bir göç için hazırlamanız gerekiyor. "Hakkında" kutusu gibi küçük bir formla başlayın ve basit formlardan karmaşık formlara geçin. Elbette bazı geçişleri bir araya getirmeniz ve planlamanız gerekecek, ancak ekranlarınızı, raporlarınızı ve kitaplıklarınızı Ms Access'ten VB.Net'e geçireceksiniz.

Bütün bunları Access ile yaptığınıza şaşırdım. .NET Windows Forms veya .NET WPF'e sormamanız gereken çok önemli bir soru var. WPF'nin daha dik bir öğrenme eğrisi var, ancak bence daha iyi bir UI ile daha güçlü. Son zamanlarda ticari uygulamamızı Formlardan WPF'ye çevirdik ve şimdiden daha fazla satış elde ediyoruz. Ayrıca yeni özellikler ekledik, ancak WPF UI sadece daha seksi. Masa tasarımınızı gözden geçirin ve temizleyin - şimdi tam zamanı. Tüm FK'lerinizi bildirdiğinizden emin olun. Access'te, bazı şeylerin kolayca kaydığı bazı şeyleri anında ekleyebilirsiniz. Bu sizin ilk WPF UI'nızsa bazı prototipler oluşturun. Yeni uygulamanın daha fazla özelliğe, daha az ekrana ve daha az çok daha az koda sahip olması için WPF'ye daha fazla paketlenebiliriz. XAML'den nefret etmekten ne kadar sevdiğine kadar gideceksin. MVVM gibi bir yapı düşünün.

Access nesne modelini zaten iyi anladığınızdan, .NET uygulamanızdan Access Interop kullanmak istediğinizi düşünüyorum . Bu, (az ya da çok), bir DDE'nin opaklığı olmadan bir Access uygulamasının kontrolünü otomatikleştirmenize izin vermelidir.

İş mantığı katmanınız hakkında derin bir bilgi bilmiyorum, ancak MS Access veritabanlarınıza .NET uygulamanızdan da erişebilirsiniz. Sadece veri almakla ilgili değilse, programlarınız arasında bir TCP / IP bağlantısı kurabilirsiniz (VB6 ve VB.NET uygulamaları). Lütfen CodeProject ile ilgili bir makaleye bakın .

Yanlış olanı nasıl yapacağınızla ilgili en iyi uygulamayı arıyorsunuz. Bir tane yok. En iyi uygulamalar etkili bir şekilde nasıl idare edilebilir bir sistem oluşturulacağını kapsar, böylece bir otobüs çökerse ve yepyeni bir ekibin soğumaya ihtiyacı olsa bile, geliştirme ve destek devam edebilir. Tanımladığınız sistem, tepelerde çalışan çoğu geliştiriciyi gönderecek. Eski teknoloji ile üretilmiş bir ürüne sahipsiniz ve günümüz teknolojisi ile arayüz oluşturmak istiyorsunuz. Ve bunu, çekirdek ürün için tanımladığınız anti-paternlerden herhangi birine değinerek yapmak istiyorsunuz. Başa çıkmak isteyen geliştiriciler, muhtemelen teklif ettiğiniz şartlarla bunu yapmak istemeyecektir.

Bununla birlikte, otobüsünüz çökmedi, bu yüzden sistemi anlayan mevcut takımdan yararlanabilirsiniz. Bulduğum yavaş yavaş gelişmenin en iyi yolu Çevik Metodolojiyi kullanmak. Erken dönemde yüksek risk gereksinimlerini karşılayan ve iş gereksinimlerini iyi karşılayan yinelemeli bir süreci destekler.

Uygulamamızı kademeli olarak .Net'e kaydırmaya karar verdik.

Genellikle bir hata. En iyi uygulama "yavaş yavaş" denememek.

Buradaki geliştiricilerin çoğu için yeni bir dil olsa da, VBA ve VB6'da uygulanan birkaç düzine proje hakkında derin bilgiye sahibiz.

Karar için çok iyi bir temel değil. Yeni bir dil öğrenmek istiyorsanız, VB öğrenmeyin. C # veya Java gibi daha iyi bir şey öğrenin.

"Buradaki geliştiricilerin çoğu için yeni bir dil, VBA hakkında derin bilgiye sahibiz", "tahriş etmek istemediğimiz bir VBA Gurusu var" için ortak bir kod ifadesidir. Bu da muhtemelen kötü bir şey.

Bizim aradığımız şey, geniş GUI'lerimizi yavaş yavaş hareket ettirmek için en iyi uygulamalar

En iyi uygulamalar "Kademeli" anlamına gelmez. "Tamamen At" ı içerirler.

Gördüğüm kademeli göçler bozuldu çünkü çok zor.

Bunu yapman daha iyi.

1. En değerli varlığı koru . Veri. Tüm verileri SQL Server'a taşıyın. Hepsini. SQL Server'a ODBC bağlantılarını kullanmak için tüm MS-Access'i yeniden yazın. Şimdi.

2. MS-Access'te geçici tablolar veya veriler oluşturan herhangi bir kişiyi kovun. Tüm veriler MS-Access dışındaki bir veritabanında yaşamak zorundadır. MS-Access'teki veriler sorunlara neden olan şeydir, bu yüzden şimdi durun ve herkesin aynı fikirde olduğundan emin olun. Kabul etmiyorlarsa, MS-Access'ten kurtulmaya çalışırken, MS-Access'te bilgisayar korsanlığı içermeyen yeni bir iş bulun.

3. Şu anda sahip olduklarınıza yakın otomatik olarak raporlar oluşturacak bir raporlama çerçevesi bulun. Programlama yok Sadece bir masa veya bir görünüm ve bang ver! bitti.

4. 500 raporun tümünü numaralandırın. Onları araçla kolayca oluşturulan raporlara ve daha zor raporlara ayırın. Zor olanları "Olmalı", "Olmalı", Olmalı "ve" Daha Sonra Olmayacak "olarak önceliklendirin Otomatik raporları ve sahip olması gereken raporları tamamen MS-Access dışında raporlayın.

   Tecrübelerime göre, bir veritabanı görünümü genellikle yaklaşık 20 raporda tekrar kullanılır. Bundan, 500 raporun türetildiği ilgili 25 görüşünüz olduğunu tahmin ediyorum. Rapor üretimini otomatikleştirebilecek herhangi bir araç, raporlarınızın çoğunu küçük bir dizi iyi hazırlanmış SQL görünümünden almalıdır. Otomatik bir araç için birkaç rapor çok karmaşık veya zor olacaktır.

5. CRUD işlemlerini otomatik olarak yapan bir geliştirme çerçevesi bulun.

6. 200 formunuzu CRUD formlarına (otomatik olarak oluşturulabilir) ve CRUD olmayan formlara ayırın. CRUD olmayanlar arasında MoSCoW (Zorunlu, Olmalı, Olabilir, Olmaz) kurallarını kullanarak öncelik verin.

   Genellikle, başvuru formlarının% 60-80'i basit, otomatik CRUD formlarıdır. % 20-40'ı daha karmaşıktır ve daha yetenekli programlama gerektirir. Buna dayanarak, yeniden yazmak gerekmeyen 120 ila 160 CRUD formunuz var, sadece otomatikleştirin. 40-80 ciddi şekilde karmaşık işlemleriniz var.

7. CRUD formlarını ve CRUD içermeyen formları oluşturun.

8. Boşlukları değerlendirin. "Olmalı" listesinin en önemli kısımları üzerinde tekrar öncelik verin ve çalışmaya başlayın.

Access'i tamamen atmak muhtemelen en kolay yoldur. Aşamalı olmaktan kaçının.

Sonunda tüm parayı harcayacaksın.

Bunun için de bütçe ve şimdi harcayabilirsiniz.

Bunu aşamalı olarak yapmaya çalışmak, birlikte yaşamaya devam etmenin karmaşıklığı nedeniyle daha pahalı olabilir .