Verimliliği korurken kullanıcı arayüzünü iş mantığından nasıl ayırabilirim?

Diyelim ki bir birleşik giriş kutusundaki 10 farklı nesneyi temsil eden bir form göstermek istiyorum. Örneğin, kullanıcının domates içeren 10 farklı olandan bir hamburger seçmesini istiyorum.

Kullanıcı arayüzünü ve mantığı ayırmak istediğim için, onları açılan kutuda görüntülemek için hamburgerlerin dize olarak sunulması gerekir. Aksi takdirde, kullanıcı arayüzü nesne alanlarını kazmak zorunda kalır. Sonra kullanıcı, birleşik giriş kutusundan bir hamburger seçer ve denetleyiciye geri gönderir. Şimdi kontrolör, form tarafından kullanılan dize temsilini (belki bir ID?) Temel alarak tekrarlanan hamburguer'ü bulmak zorunda kalacaktır.

Bu inanılmaz derecede verimsiz değil mi? Birini seçmek istediğiniz nesnelere zaten sahipsiniz. Forma tüm nesneleri gönderdiyseniz ve sonra belirli bir nesneyi döndürdüyseniz, form zaten bu nesneye bir başvuru döndürdüğü için bunu daha sonra hatırlatmanız gerekmez.

Dahası, yanılıyorsam ve aslında tüm nesneyi forma göndermeniz gerekiyorsa, kullanıcı arayüzünü mantıktan nasıl yalıtabilirim?

^{Her şeyden önce, verdiğiniz örnek inanılmaz derecede verimsiz değil; sadece biraz verimsiz; verimsizliği algılanabilir seviyenin altında. Ancak, her durumda, soruya devam edelim.}

Anlama şeklimiz , kullanıcı arayüzü ve mantığın ayrılması söz konusu olduğunda , yakın bağlantıdan kaçınmak anlamına gelir .

Yakın bağlantı , UI'nin mantığı tanıdığı (ve çağırdığı) ve mantığın UI'yi tanıdığı (ve çağırdığı) anlamına gelir. Yakın bağlantıdan kaçınmak için, bağlantıyı tamamen ortadan kaldırmak gerekmez. (Aralarındaki arabirimi en az ortak paydalı dize arabirimine yıkarak hedeflediğiniz gibi görünüyor.) Tek yapmanız gereken gevşek bağlantı kullanmaktır .

Gevşek bağlantı A B bilir ama B Başka bir deyişle A. bilmediği araçlar, iki parti dahil oyun farklı istemci ve sunucu istemci sunucu bilir, ancak sunucu istemci bilmiyor rolleri.

Kullanıcı arayüzü ve mantık söz konusu olduğunda, bunu düzenlemenin en iyi yolu, mantığı bir sunucu ve kullanıcı arayüzünü bir istemci olarak görmektir. Böylece, UI mantık için inşa edilmiştir, mantık bilgisine sahiptir ve mantığı UI hakkında hiçbir şey bilmez ve mantığı UI hakkında hiçbir şey bilmez ve sadece aldığı isteklere yanıt verir. (Ve bu istekler UI'den geliyor, ancak mantık bunu bilmiyor.)

Daha pratik terimlerle ifade etmek gerekirse, mantığın kaynak kodu dosyalarının hiçbir yerinde UI dosyalarına atıfta bulunan include / import / using ifadeleri bulamazken, UI'nin kaynak kod dosyaları include / import / using ile dolu olacaktır. Mantık dosyalarına başvuran ifadeler.

Davanıza geri dönmek için, birleşik giriş kutusunu dolduran UI kodunun hamburger sınıfını bilmesi kesinlikle yanlış bir şey değil. Hamburger sınıfı birleşik giriş kutuları hakkında bir şey biliyorsa bir sorun olurdu.

Bu arada, bu tasarım böyle bir sistemden beklemeniz gereken başka bir şeye izin verir: mantığa istediğiniz kadar farklı kullanıcı arayüzü eklemek mümkün olmalı ve her şey hala çalışmalıdır.

Model, Görünüm ve Denetleyicinin her bir parçasını ayırmalısınız , ancak Model nesnelerini Denetleyici ve Görünüm arasında geçirememenizin (örneğin) bir nedeni yoktur.

Yani sizin durumunuzda, Hamburgernesneler Modelin bir parçası olacaktır. Daha sonra gerekli Hamburgers listesini almak için Denetleyicinizi kullanın ve bu nesneleri görüntülemek için Görünüm'e (birleşik giriş kutusu) iletin. Kullanıcınız hangi hamburgeri seçtiğinde, Hamburgernesneyi işlenmek üzere tekrar Kontrolöre iletebilirsiniz .

Mesele şu ki, "getir Hamburger" mantığını ve "işlem Hamburger" mantığını hamburgerlerin gerçek ekranından ayrı olarak birim test edebilirsiniz .