Temiz Mimari - Çok Fazla Kullanım Vaka Sınıfı

Ben giriyorum Temiz Mimarlık ve MVC gelen için Android seviyesini asansör MVP RxJava 2 ile Dagger 2, Reaktivite ile DI tanıtan, ve tabii ki Java 8.

In MVP temiz mimarisi bir orada varlıklar arasındaki katman (veri depolarına olarak) ve sunum bunlara erişmek gerekir. Bu katman "Kullanım Durumu" dur . Bir kullanım durumu, ideal olarak, bir varlık üzerinde BİR işlemi uygulayan bir arabirimdir.

Ayrıca, Clear Architecture'ın “ çığlık attığını ” biliyorum , projeleri anlamında gerçekten çok fazla sınıf olarak okunabilir.

Şimdi, projemde , 6 farklı varlık gibi bir şey var ve elbette, her varlık havuzunun bunlara erişmek için en az 4 yöntemi (genellikle al, ekle, sil, güncelle) var .. yani, 6 * 4 = 24 .

Temiz Mimari şimdiye kadar anladım , 24 UseCase sahip olacak.

MVC sadece 6 denetleyicileri ile karşılaştırıldığında bu bir çok sınıftır .

Gerçekten 24 kullanım durumu yapmak zorunda mıyım?

Bunu zaten başarıyla kullanan birisinin açıklamasını gerçekten takdir edeceğim.

Teşekkürler Jack

— Jackie Degl'Inocenti
kaynak

Bu Kullanım Durumlarını ayrıntılı olarak açıklayan bir sayfaya örnek kodla bir bağlantı gönderebilir misiniz?

— Robert Harvey

Çok googled, ama esas olarak: bu uygulama örneği ve ilgili makale: github.com/jshvarts/OfflineSampleApp ; bu makaleler: proandroiddev.com/… ; proandroiddev.com/… ; Bu Tartışma: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; Ve bu makaleler de: adityaladwa.wordpress.com/2016/10/25/…

— Jackie Degl'Innocenti

Belirttiğiniz örnek uygulamaların veya makalelerin hiçbirinin Temiz Mimari ile ilgisi yok gibi görünüyor. Ancak, reaktif programlama

— Robert Harvey

Örnek uygulama kesinlikle Temiz Mimari paradigması ile yapılır .. Diğer makaleler çoğunlukla .. @RobertHarvey ne görmek istiyorsun?

— Jackie Degl'Innocenti

Aşağıdaki cevabımı okuyun ve cevaplayın.

— Robert Harvey

Yanıtlar:

Gerçekten 24 kullanım durumu yapmak zorunda mıyım?

Sadece yazdığınız her şey CRUD ise .

Aşağıdaki şemaya bakın:

İddianız, altı farklı varlık ve her varlık için 4 yöntem (Oluşturma, Okuma, Güncelleme ve Silme) olacaktır. Ancak bu yalnızca diyagramın ortasındaki sarı nesneler için geçerlidir (Varlıklar katmanı). Kullanım Durumları katmanında yalnızca CRUD çağrılarından Varlıklar katmanına geçen 24 yöntem oluşturmak anlamsızdır.

Kullanım Durumu "Müşteri Kaydı Ekleme" değildir. Bir Kullanım Örneği, Fatura Başlığı ve Fatura Satır Öğelerine ek olarak "Müşteriye bir ürün sat" (Müşteri, Ürün ve Envanter varlıklarını içeren) veya "Faturayı yazdır" (aynı varlıkları içeren ) satırları boyunca geçerlidir. ).

Kullanım Örnekleri oluştururken , CRUD yöntemlerini değil , ticari işlemleri düşünmelisiniz .

Daha Fazla Okuma
Toplamı - tek bir birim olarak ele alınabilecek etki alanı nesneleri kümesi

— Robert Harvey
kaynak

Kalıpları, uygulamaları ve mimariyi düşünmek için çok fazla zaman harcıyorsunuz ve temel yazılım tasarımı hakkında düşünmek için yeterli zamanınız yok. Tek ihtiyacım olan, cevabımda açıkladığım gibi, iş uygulamalarını somutlaştıran yöntemlerdir.

— Robert Harvey

Bu bir mimari seçme meselesi değil. Benim kişisel fikrim: çıplak CRUD operasyonları doğrudan Varlık Katmanı ile konuşmalıdır. Tabii ki, bu muhtemelen Temiz Mimariyi ihlal ediyor.

— Robert Harvey

Bir noktayı kaçırıyorsun. Mimari sadece kodu organize etmenin bir yoludur. Problemleri mimarlarla güreşmeden kod yazarak çözersiniz.

— Robert Harvey

Hey Robert, kod yazmadığımı varsayman o kadar hoş değil. Cevabımın konusu mimari, ve biz SO'da değiliz. Saygılarımla, son yorumlarınızı gerçekten yanıltıcı ve sağır buluyorum. Soru, Clean Arch. İçindeki UseCase ile ilgili, kod yazmayla ilgili değil. Bir şeyi iletmeye çalışıyorsanız, lütfen daha iyi açıklayın, çünkü yorumlarınızın noktasını kaçırıyorum. IMHO, yazılım geliştirirken Mimarlık düşüncesinden kaçınmak mümkün değildir, ya da en azından iyi geliştiriciler sadece bir grup kod yazmakla kalmaz. Ayrıca yorumumda gerçekten özel bir soru sordum, cevap verebilir misiniz? Teşekkürler

— Jackie Degl'Innocenti

Sorguladığınız sorunun çözümü (önce uygulama çevrimdışı) Temiz Mimari ile pek bir ilgisi yok. Temiz Mimari diyagramında bu soruna bir çözüm bulamazsınız.

— Robert Harvey

Her CRUD İşleminin tek bir UseCase dilinde çevrilmiş olması durumunda haklısınız. Ancak bir UseCase birden fazla CRUD-İşleminden de oluşabilir.

UseCase ayrı bir modeldir ve farklı veri kaynaklarından bilgi toplar ve veri havuzlarıyla iletişim hazırlar. Birden fazla CRUD Operasyonu söz konusu olabilir.

Bu nedenle, bir müşteri için fatura oluşturmanın ve müşterinin kendisini de yarattığı, çünkü sistemde bulunmadığı bir UseCase'i düşünün. Bir işlemde en az iki Oluşturma İşlemiyle sonuçlanan bir UseCase var.

— oopexpert
kaynak

Pek çok varlıkla CRUD örneği için hangi modeli önerirsiniz?

— Jackie Degl'Innocenti

Benim kişisel görüşüm şudur: SRP'yi (tek sorumluluk ilkesi) ihlal etmedikleri sürece birçok sınıfa sahip olmakta sorunum yok. Ancak çoğu zaman "bir varlık oluştur", "bir varlığı güncelle", "bir varlığı sil" ve "bir varlığı" basit bir "X türünü yöneten varlığa" güncelleyin. Genellikle bir varlığı yönetmek için tek bir kullanıcı arayüzü sağlarsınız. Ancak UseCase'iniz tam olarak bunu tanımlamalıdır: İşletmeniz için yararlı bir iş yükünü ele almanın yolu.

— oopexpert

Tamam, bu nedenle, çeşitli farklı işlemleri yöneten bir Kullanım Durumuna sahip olmak, herhangi bir tek akış birden fazla sorumluluk üstlenmeden aynı UseCase'de yalnızca daha farklı yöntemleri (ve akışları) "bir araya getirdiği" gibi SRP'yi ihlal etmiyor gibi görünüyor. .. ama bu şekilde sadece bir UseCase yerine bir kontrolör oluşturmuyor muyuz? .. fikir .. Belki Kullanım Örneği basitçe bir katman olarak görülmelidir ve bu katman SRP'ye saygı göstermek zorundadır, ancak birçok yöntemi de uygulayabilir. Bununla ilgili bir kaynak veya makale istiyorum

— Jackie Degl'Innocenti

Bir Usecase IS Bir denetleyicidir. Tek fark, bir usecase'in iş perspektifinden gelmesi ve bir denetleyicinin teknik bakış açısı olmasıdır. Bir kullanıcı tabanının odağı, iş değerini yaratan şeydir. Yani bir usecase, iş değeri odaklı bir denetleyici uygulamasıdır.

— oopexpert

Kabul et, bir HTTP denetleyicisi G / Ç'yi yönetmenin bir yoludur, ayrıca konsol komutları, olay tepkileri ve benzeri de olabilir. Tüm bu G / Ç kanalları aynı kullanıcı tabanını çağırır. Bir usecase, iş mantığı için bir denetleyicidir, çağrıldığı G / Ç kanallarını bilmez, ancak işi yapmak için etki alanı varlıklarının nasıl düzenleneceğini bilir.

— Dmitriy Lezhnev

Kullanım Örneği tanımınız yanlış, Kullanım Örneği bir iş kuralı uygulayan bir sınıftır, bir CRUD işlemi olması gerekmez, karmaşık çok adımlı bir işlem olabilir

— Buckstabue
kaynak

Cümleniz aslında çok çeşitli Crud benzeri operasyonlar uygulamanız gerektiğinde bir çözüm anlamına gelmez, düşünmeniz bile bir Kullanım Vakasının karmaşık bir operasyona erişebileceğimiz bir kalıp gözlemlemesi gerektiği ile ilgili bir ilişki bulabilir, hatta çok adım.

— Jackie Degl'Innocenti