ASP.NET WebForms Uygulaması için En İyi Mimari

Bir istemci için bir ASP.NET WebForms portalı yazdım. Proje, başlangıçtan itibaren düzgün bir şekilde planlanmak ve yapılandırılmak yerine bir tür evrim geçirmiştir. Sonuç olarak, tüm kod aynı proje içinde ve herhangi bir katman olmadan birlikte ezilir. İstemci şimdi işlevsellikten memnun, bu yüzden projeyi serbest bırakmak konusunda emin olacağım şekilde kodu yeniden düzenlemek istiyorum. Mimariyi tasarlamanın birçok farklı yolu var gibi göründüğü için, alınacak en iyi yaklaşım hakkında bazı görüşler istiyorum.

İŞLEVSELLİĞİ

Portal, yöneticilerin HTML şablonlarını yapılandırmasına izin verir. İlişkili diğer "ortaklar", sitelerine IFrame kodu ekleyerek bu şablonları görüntüleyebilir. Bu şablonlarda müşteriler ürün kaydı ve satın alma işlemi gerçekleştirebilir. WCF kullanılarak harici şirketlerin sistemle arayüz kurmasına izin veren bir API uygulanmıştır. Yönetici bölümü, Yöneticilerin her bir iş ortağı için çeşitli işlevleri yapılandırmasına ve raporları görüntülemesine olanak tanır. Sistem müşterilere faturalar ve e-posta bildirimleri gönderir.

GÜNCEL MİMARLIK

Şu anda veritabanını okumak / yazmak için EF4 kullanıyor. EF nesneleri doğrudan aspx dosyalarında kullanılır. Bu siteyi yazarken hızlı gelişimi kolaylaştırdı, ancak db'yi UI ile sıkıca bağladığı için muhtemelen böyle tutmak kabul edilemez. EF nesnelerinin kısmi sınıflarına belirli iş mantığı eklendi.

SORULARI

Yeniden düzenleme işleminin amacı, siteyi ölçeklendirilebilir, kolay korunabilir ve güvenli hale getirmektir.

1. Bunun için ne tür bir mimari en iyi olurdu? Lütfen DTO / POCO / Aktif Kayıt modelini kullanmam gerekip gerekmediğini, her katmanda ne olması gerektiğini açıklayın.

2. DTO'ları / BO'ları otomatik olarak oluşturmanın sağlam bir yolu var mı, böylece ekstra katmanlara rağmen gelecekteki geliştirmelerin uygulanması basit olacak mı?

3. Projeyi WebForms'tan MVC'ye dönüştürmek faydalı olur mu?

ASP.NET MVP deseni , uzun vadeli bir ASP.NET webformları uygulaması için en iyi mimaridir . MV * modellerinin arkasında bir eğilim olan “endişelerin ayrılması” konseptiyle devreye giriyor.

Soru Why kullanmak? - bu yayında ayrıntılı olarak ele alındı ​​- ASP.NET MVP

• Bir ASP.NET Webforms Uygulamasını test etmeye başlama
• MVP ve MVC arasındaki ödünleşimler
• Karışıklık Sonu: MVP ve MVC

1. Ayrı ve mantık ve kullanıcı arayüzü için MVP desenini kullanın, böylece gelecekte mevcut mantığı yeniden kullanarak farklı bir kullanıcı arayüzü teknolojisine geçebilirsiniz
2. İş mantığını yeniden kullanan herhangi bir RDBS'ye geçebilmeniz için BL ve DAL arasındaki depo modelini kullanın
3. Bakımı en aza indiren BO ve DAL için ayrı katmanlar (Dll) getirin.

ElYusubov'un belirttiği gibi, MVP paterni harika olabilir.

Anahtar kavram, mantığınızın çoğunu veya tamamını arka plan kodundan çıkarmaktır. Mantık bir sayfaya bağlı olmamalıdır. Bir sayfadaki mantığı başka bir sayfada yeniden kullanmanız gerekirse ne olur? Kopyala ve yapıştır için cazip olacaksınız. Bunu yaparsanız, projeniz sürdürülebilir hale gelecektir.

Bu nedenle, yeni başlayanlar için mantığınızı arkadaki koddan yeniden düzenlemeye başlayın ve bir iş katmanına yerleştirin. Tüm mantığı kodun arkasından çıkarmayı başardıysanız, gerçek bir MVP olmak için gerekli arayüzleri uygulayabilirsiniz.

Ayrıca, veri erişiminizin iş mantığınızdan ayrı olduğundan emin olun. Bir veri katmanı oluşturun ve bu konuda da yeniden düzenlemeye başlayın. EF4 kullandığınız için, EF'in zaten bu ucu ayrı olması gerektiği için bu daha az problemdir. Tüm EF dosyalarınızı başka bir projeye kolayca taşıyabilmeniz ve ihtiyacınız olan projelere bir referans eklemeniz gerekir. Ek fayda, diğer projelerde veri modelinize başvurmanız gerekebilir.

Bunalmış olmaktan kaçınmak için her seferinde biraz yeniden odaklanın. Bir kod parçasına dokunduğunuzda, etrafındaki kodu yeniden düzenlemeyi düşünün. Bunu yaparsanız, zamanla projeniz daha sürdürülebilir hale gelebilir.

Düzenle

Kodun ardında bir iş mantığı sınıfı devralmasını istediniz. "İs-a" sayfasının arkasındaki kod olduğu için bu yapılamaz. C #, birden çok kalıtıma izin vermediğinden, arka plan kod sınıfı hem bir sayfa hem de özel bir nesne olamaz. Kavramsal olarak mantığı ayırmanız gerekir. Muhtemelen arkadaki kodunuzdaki kod birçok farklı şey yapıyor. Bir sınıf sadece bir şey yapmalı. Mevcut işlevselliği kavramsal olarak nasıl çıkarabileceğinizi düşünmeye çalışın. Örneğin, bir kayıt sayfanız olduğunu ve kullanıcı bilgilerini topladığınızı varsayalım. Muhtemelen register adlı bir düğmeniz ve bu düğmeyle ilişkili bir tıklama etkinliğiniz var. Bu durumda kullanıcı bilgilerini kaydediyor ve ihtiyacınız olan her türlü işlemi yapıyorsunuz. Tüm bu mantığı işlemek için bir Kayıt nesnesi oluşturabilirsiniz.

Bu sadece daha temiz bir ayırma değil, aynı zamanda kodunuzu kendiniz belgelemenin bir yolu olabilir. Birisi kodunuzu okuduğunda sizi bir Kayıt nesnesi olarak adlandırdığınızı görür, böylece neler olduğunu tam olarak bilirsiniz.

MVP modelini sıkı bir şekilde takip etmek istiyorsanız, parametreleri Kayıt nesnesine geçirmek yerine, arkadaki kod bir arabirim uygular. Arayüzün uygulanması temel olarak tüm görünüm nesnelerini (metin alanı vb.) Arayüzle eşler. örneğin public string FirstName {get {return txtFirstName.Text; }}

Bu yapıldıktan sonra sayfayı Kayıt nesnesine aktarabilirsiniz

Registration.RegisterUser (bu);

Ve bu RegisterUser yöntemi, arabirimi parametre olarak alır

public bool RegisterUser (IUser kullanıcısı) {user.FirstName ...}

genel arabirim IUser {genel dize FirstName; }

Bu MVP kafa karıştırıcı geliyorsa, sadece yeniden düzenlemeye odaklanın ve tüm bunların amacının kodun yeniden kullanımını en üst düzeye çıkarmak olduğunu bilin. Kendinizi tekrarladığınızdan beri yok. Bu KURU prensibi .