Geliştirme Yaklaşımı: Kullanıcı Arayüzü Girişi veya Etki Alanı Modeli Çıkışı?

Smalltalk kullanarak hiçbir şey teslim etmeme rağmen, onunla oynadığım kısa zaman kesinlikle izini bıraktı. Deneyimi tanımlamanın tek yolu MVC'dir. Esasen, uygulamanız için tüm ağır kaldırma iş nesnelerinde (veya çok eğimli iseniz etki alanı modelinde) yapılır. Standart kontroller bir şekilde iş nesnelerine bağlıdır. Örneğin, bir metin kutusu bir nesnenin alanıyla eşlenir (alanın kendisi bir nesnedir, bu nedenle yapılması kolaydır). Bir düğme bir yönteme eşlenir. Tüm bunlar çok basit ve doğal bir API ile yapılır. Bağlama nesneleri vb. Hakkında düşünmek zorunda değiliz. Sadece işe yarıyor.

Yine de, birçok yeni dilde ve API'da dışarıdan düşünmek zorundasınız. İlk olarak C ++ ve MFC ile ve şimdi C # ve WPF ile Microsoft, olay işleyicilerini uygulayarak uygulamanızı oluşturduğunuz GUI oluşturucularına bağlı geliştirici dünyasına kavuştu . Java Swing geliştirme çok farklı değil, sadece formdaki denetimleri kendiniz başlatmak için kodu yazıyorsunuz. Bazı projeler için hiçbir zaman bir etki alanı modeli olmayabilir - yalnızca olay işleyicileri. Kariyerimin çoğu için bu modelin içinde ve çevresinde bulundum.

Her yol sizi farklı düşünmeye zorlar. Smalltalk yaklaşımıyla, GUI'niz aptalken alan adınız akıllıdır. Varsayılan VisualStudio yaklaşımıyla, etki alanı modeliniz (varsa) oldukça anemikken GUI'niz akıllıdır.

Birlikte çalıştığım birçok geliştirici Smalltalk yaklaşımında değer görüyor ve VisualStudio ortamına yaklaşmayı deniyor. WPF'nin bunu mümkün kılan bazı dinamik bağlama özellikleri vardır; ancak sınırlamalar vardır. Kaçınılmaz olarak, etki alanı modeline ait bazı kodlar GUI sınıflarında son bulur.

Peki, kodunuzu hangi yolla tasarlıyorsunuz / geliştiriyorsunuz? Neden?

• Önce GUI. Kullanıcı etkileşimi çok önemlidir.
• Önce alan adı. Bir kullanıcı arayüzü koymadan önce sistemin doğru olduğundan emin olmalıyım.

Her iki yaklaşım için de artıları ve eksileri var. Etki alanı modeli, gökyüzünde kristal katedraller ve turta ile uyuyor. GUI orada hızlı ve kirli (bazen gerçekten kirli) ile uyuyor.

Ek bir bonus için: Kodun korunabilir olduğundan nasıl emin olabilirsiniz?

ne

Yazılım geliştirdiğim yıllar boyunca kendimi her iki ilk metodolojiyi uygulamak için buldum çünkü her zaman dikkate alınması gereken bir "orta zemin" var. Kullanıcı arayüzü kodu ile işletme kodu arasına bir arayüz koyun ve kullanıcı arayüzünün şu anda alan adından neye ihtiyacı olduğu konusunda bir anlaşma yapın.

Bu konsepti kristalleştirmek için bir figür yapmama izin verin:

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

Bu şekilde, orta zemin kullanıcı arayüzünün hangi verileri alabileceği konusunda netleşirse, kullanıcı arayüzü ve alan adı modeli üzerinde ayrı ayrı tekrarlanabilir.

Bazı projeler haline anlıyorum nedeni unmaintainable veri ve sunum arasında arayüz olmuştur çünkü koştu veya yok olan (doğrudan veri ui içindedir kodu işleyebilecek ile). Ben veritabanı kodu form kodu içinde ikamet o kadar çok proje gördüm ki insanlığa inancını kaybettim. Bu sert orta zemine sahip olduğunu gördüğüm sadece birkaç proje inancını yitirdi.

Bu hangi gerçekten önemli değil sonuna önemli olan şudur ki var olduğunu ... ilk başladığı yer o yerde kaygıları açık ayırma. Ortadaki bu sözleşme, eldeki uygulamayı veya sistemi hemen hemen tanımlar. Aşağıdan yukarıya veya yukarıdan aşağıya gitmeden önce bunu bir düşünün .

Önce alan adı. Bir kullanıcı arayüzü koymadan önce sistemin doğru olduğundan emin olmalıyım.

Basit durumlar dışında başka hiçbir şey işe yaramaz.

Kullanıcı arayüzünden başlamak, genellikle eğlenceli görünebilecek, ancak modelde ciddi sorunları olan kırılgan, buggy yazılımlarına yol açar.

UI'nin ilk önce başarısızlığa mahkum olduğu verilmiş değildir - eğer model yeterince basitse, UI ilk olarak modelin sonunda iyi çalışacağına güvenle inşa edilebilir.

Modelin kolayca hayal edilemediği her durumda, önce oluşturulması gerekir.

En kötü durum, bazı programcıların modeli hayal edebileceklerini düşündüğü yerdir. Önemli ayrıntıları, özel durumları, istisnaları veya performans hususlarını atlamış olabilirler. GUI zaten oluşturulduğundan ve atlandığı yerlerde birçok hususdan dolayı, model korkunç.

Bu gerçekten eldeki uygulamaya bağlıdır.

Kapalı bir istemci / sunucu uygulaması oluşturuyorsanız, her iki yaklaşım da yeterli olacaktır; arka ucunu kaçınılmaz olarak ön uçlara uyacak şekilde manipüle edeceğiniz için.

Potansiyel bir web hizmetinin müşterileriniz tarafından kullanılmak üzere açık olacağı bir açık istemci / sunucu uygulaması oluşturuyorsanız, bu hizmetin bir müşteri tarafından bir kullanıcı arabirimi geliştirmek için nasıl kullanılabileceğinin farkında olmak çok önemlidir.

Çoğu zaman, geç gelişmekte olan küçük iteratif döngülerin (Scrum, Kanban, vb.) İtilmesiyle ilgili olarak ön uç ve arka uç paralel olarak yapılır. Bu, yineleme verildiğinde ihtiyaç duyduğunuz şeyleri sağlamakla ilgilidir; yaklaşıma ihtiyacımız olması durumunda inşa etmeyi göz ardı etmek . Paralel bir yaklaşımla, her iki uç da geliştirme boyunca çok daha yakın durur, bu da ön uç ve arka uç birleştiğinde sürekli değişiklik ihtiyacını azaltabilir. Mümkün olduğunda tercih ettiğim yaklaşım budur.

Bahsettiniz ...

... WPF bunu mümkün kılan bazı dinamik bağlama özelliklerine sahiptir; ancak sınırlamalar vardır. Kaçınılmaz olarak, etki alanı modeline ait bazı kodlar GUI sınıflarına girer ...

Bazıları ile ne demek istediğinizden emin değil misiniz ? WPF ve SL'nin her ikisi de bağlanma işlevleri nedeniyle not edilir. Sonsuz. MVVM tabanlı bir WPF uygulamasında Görünümünüzün içine kod yerleştirmek zorunda kalıyorsanız o zaman bir şey ele alınması gerekiyor. Ekli Davranışlar , Görünüm içindeki olaylara bağlanmadan davranışı uygulamanın bir yoludur ve ayrıca Görünümünüzün temiz kalmasını sağlamak için diğer birçok yaklaşımdır.

Kullanıcı etkileşimi duruşunun ön ucunun , arka uç uygulamasıyla bir ilgisi olmamalıdır . Arka taraf tek bir işin ön ucuna veri işleme verileri veya diğer yollarla veri sağlamaktır. Bu, geliştirilmekte olan uygulama türüne bağlanır.

Kaynak kodun korunabilir olduğundan emin olmak kendi başına tamamen farklı bir sorudur. Üst düzeyde, kanıtlanmış desen, mimariler ve teknolojilerin yanı sıra en iyi kodlama uygulamalarıyla da ilgilidir.

İlk olarak temel kullanıcı arayüzünü (yalnızca kağıt üzerinde olsa bile), müşterinin girdisi ile tasarlamayı tercih ederim. Müşteri, görene kadar ne istediğini gerçekten bilmiyor olabilir. Müşterinin size söylediklerine her zaman güvenemezsiniz. Sağlam bir alan adı modeli yazarak haftalar için yatırım yapabilir, ancak müşterinin kullanıcı arayüzü prototiplerini görmeye başladıktan sonra istediklerine uymadığını öğrenebilirsiniz.

Yazılımımızı otomatik testlerle çalıştırmaya çalışıyoruz. Otomatik UI testi oldukça zaman alıcıdır. Bir konsoldaki bazı değerleri kontrol etmek için komut dosyaları daha kolaydır.

Bunu göz önünde bulundurarak, iş mantığını kullanıcı arayüzünden ayrı tutmaya oldukça dikkat ediyoruz.

Bir kez bir baş geliştirici bile bana tüm iş kodumuzu UI ile bağlamayı durdurmamız gerektiğini önerdiğimde Belge / Görünüm mimarisinin eski olduğunu düşündüğümü bile hatırlıyorum (ve o zamanlar C ++ 'da win32 kullanıyorduk. bizim sorunumuz bile değildi). Sadece şaşkındım.

IMNSHO, en azından bir işletme ve kullanıcı arayüzü katmanına sahip olmamanın hiçbir mazereti yoktur. Ürününüz biraz ilginç bir şey yapıyorsa, bu ayırmanın kodun yeniden kullanımını etkinleştirmesi kesinlikle gereklidir.

Bir C # geliştiricisi olarak, kesinlikle dışarıda çalışmaya pigeonholed olduğunu düşünmüyorum. Aslında öncelikle alan-model yapmayı tercih ediyorum.

WPF için, açıkladığım modelin tek dezavantajı, bazen kullanıcı arayüzünüz ve alan adı modeliniz arasında aracılık yapmanız gerektiğidir. Yine de, bu bazen daha fazla iş anlamına gelirken, aynı zamanda daha temiz kod anlamına gelir.

Kesinlikle, önce etki alanı!

Smalltalk'ın güzelliği, bir etki alanı modelini bir çalışma alanından veya denetçiden "yazdırmak" da dahil olmak üzere çeşitli şekillerde kolayca "sürmek" idi. Yalnızca alan adınızın istendiği gibi performans gösterdiğinden eminseniz, mükemmel GUI oluşturmaya odaklanmaya cesaret edersiniz.

Bu, Smalltalkers'ın ikisi üzerinde aynı anda çalışmadığı anlamına gelmez, ancak GUI'niz iş mantığını uygulayamadığında, GUI'nize özel durumlar koymak yerine genellikle etki alanı modelini sabitlediniz.