Servis katmanı oluşturmak ne kadar önemlidir?

3 katlı bir uygulama geliştirmeye başladım (DAL, BL, UI) [temel olarak CRM, bazı satış raporları ve envanteri ele alıyor].

Bir meslektaşım bana servis katmanı modeline geçmem gerektiğini, geliştiricilerin deneyimlerinden servis desenlerine gelmem gerektiğini ve çoğu uygulamayı tasarlamanın daha iyi bir yaklaşım olduğunu söyledi. Uygulamayı gelecekte bu şekilde sürdürmenin daha kolay olacağını söyledi.

Şahsen, sadece işleri daha karmaşık hale getirdiği hissine kapılıyorum ve bunu haklı çıkaracak bir fayda göremedim.

Bu uygulama, bazı (ama çok az değil) bazı kod çoğaltma kendimi buldum masaüstü uygulama işlevlerinin bazılarını (ancak sadece birkaçını) kullanan ek bir küçük kısmi kullanıcı arayüzü var. Sadece bazı kod kopyalamaları nedeniyle hizmet odaklı olmaya dönüştürmeyeceğim, ama yine de kullanmam gerektiğini söyledi çünkü genel olarak çok iyi bir mimari, programcıların servisler hakkında neden bu kadar tutkulu oldukları ??

Google'ı denedim ama hala kafam karıştı ve ne yapacağım konusunda karar veremiyorum.

Martin Fowler'in "Kurumsal Mimari Desenleri" adlı kitabı şöyle:

Cevaplaması en kolay soru muhtemelen ne zaman kullanmamaktır. Uygulamanızın iş mantığında yalnızca bir tür müşteri varsa (örneğin bir kullanıcı arayüzü varsa) ve kullanım durumu yanıtlarında birden fazla işlem kaynağı içermiyorsa, bir Hizmet Katmanına ihtiyacınız yoktur. [...]

Ancak, ikinci bir müşteri türünü veya kullanım durumu yanıtlarını kullanan ikinci bir işlem kaynağını düşündüğünüzde, en baştan bir Hizmet Katmanında tasarım yapmayı öder.

Bir Hizmet Katmanının sağladığı faydalar, farklı istemciler için mevcut ortak bir dizi uygulama işlemi tanımlaması ve her bir işlemdeki yanıtı koordine etmesidir. İş mantığını tüketen birden fazla müşteri türüne sahip ve birden fazla işlem kaynağını içeren karmaşık kullanım durumlarına sahip bir uygulamanız olduğunda, yönetilen işlemlere sahip bir Hizmet Katmanı eklemenin anlamı vardır.

CRM, Satış ve Envanter ile, Servis Katmanı işlemleriyle neredeyse her zaman bire bir yazışmaların yapıldığı birçok CRUD tipi kullanım durumu olacaktır. Bir etki alanı nesnesinin oluşturulmasına, güncellenmesine veya silinmesine yönelik yanıtlar, Hizmet Katmanı işlemleri tarafından atomik olarak koordine edilmeli ve işlem yapılmalıdır.

Servis Katmanına sahip olmanın bir başka yararı da yerel veya uzaktan aramalar veya her ikisi için tasarlanmış olması ve size bu konuda esneklik kazandırmasıdır. Model, bir uygulamanın iş mantığının kapsüllenmiş olarak uygulanması ve bu mantığın çeşitli müşteriler tarafından tutarlı bir şekilde başlatılması için temel oluşturur. Bu, istemcileriniz aynı ortak hizmetleri paylaştığı için kod çoğaltmasını da azaltıp / kaldırdığınız anlamına gelir. Bakım maliyetlerini de potansiyel olarak düşürebilirsiniz - iş mantığınız değiştiğinde, (genellikle) yalnızca hizmeti değiştirmeniz gerekir, istemcilerin her birini değil.

Özet olarak, bir Hizmet Katmanı kullanmak iyidir - daha çok, bu nedenle örneğinizde birden fazla iş mantığı müşterisi gibi göründüğünüzü sağladığınızı düşünüyorum.

Fikir değerlendirilir ve en iyi yaklaşımı sonucuna çünkü bir servis katmanı ekleme: İyi

Bir servis katmanı eklemek, çünkü bütün havalı çocukların yaptığı şey: kötü

Bağırsaklarına ihtiyacın olmadığını söylüyorsa, yapma.

Programlama dünyasında son 10 yıldaki daha fazla hayal kırıklığı yaratan gelişmelerden biri, trendleri takip eden insanlar ve bu sezonun sanki ayakkabılarını izleyen insanlar ile can sıkıcı bir şekilde 'moda' haline geldi. Bu tuzağa düşme. Çünkü gelecek sezon “herkes” size başka bir şekilde tasarlamanız gerektiğini söyleyecek.

Bir servis katmanında yanlış veya doğru bir şey yoktur - eldeki projenin teknik değerleri üzerinde uygunluğunun değerlendirilmesi gereken özel bir yaklaşımdır. Başkalarının görüşlerini kendi kararınızla değiştirmeye mecbur hissetmeyin.

Servis katmanı oluşturma kararını etkileyen birçok faktör var. Aşağıdaki nedenlerle geçmişte hizmet katmanları oluşturdum.

1. Birden çok müşteri tarafından yeniden kullanılması gereken kod.
2. Sınırlı lisansımız olan üçüncü taraf kütüphaneleri.
3. Sistemimizde bir bütünleşme noktasına ihtiyaç duyan üçüncü taraflar.
4. Çoğaltılmış iş mantığını merkezileştirme.

Durum 1: Çok sayıda farklı müşteri tarafından kullanılması gereken temel işlevler yaratıyorsunuz. Servis katmanı, farklı müşterilerin kutudan çıktığında sağlanan işlevselliğinize dokunabilmesi için işlevselliği oluşturur.

2. Durum: Normalde kodu uygulama alanında barındırıyorsunuz ancak sınırlı lisansınız olan bir üçüncü taraf kitaplığı kullanıyorsunuz. Bu durumda, her yerde kullanmak istediğiniz bir kaynağa sahipsiniz, ancak bunlardan sınırlı sayıda. Bir hizmetin arkasında barındırıyorsanız, tüm kuruluşunuz her bir barındırma için bir lisans satın almak zorunda kalmadan uygulamalarından yararlanabilir.

Durum 3: Üçüncü tarafların sizinle iletişim kurabilmesi için işlevsellik geliştiriyorsunuz. Örnekte, satıcıların size gelen ürün gönderileriyle ilgili mesajları iletebilmelerini sağlamak için bir envanter bitiş noktası oluşturabilirsiniz.

Durum 4: Kod kuruluşunuzu geniş kapsamlı analiz ettiniz ve ayrı ekiplerin aynı şeyi yarattığını gördünüz (sadece biraz farklı şekilde uygulandı). Bir servis katmanı ile en iyi yaklaşımları seçebilir ve şimdi servisi tüm ekipler arasında aynı servisi uygulayarak uygulayabilirsiniz. Merkezileştirme mantığının bir başka yararı da böceklerin bulunmasıdır. Artık düzeltmeyi bir kez dağıtabilirsiniz ve tüm müşteriler aynı anda avantajdan yararlanabilirler.

Bütün bunlar söyleniyor, bir servis katmanına potansiyel olumsuzluklar var.

1. Sistem karmaşıklığı ekler. Daha önce nerede hata ayıklamak için tek bir uygulama vardı şimdi iki tane var. Üretim sorunları, istemci uygulaması ayarlarının kontrol edilmesini, hizmet uygulaması ayarlarının kontrol edilmesini veya aksi takdirde doğru şekilde ayarlanmış istemci ve sunucu uygulamaları arasındaki iletişim sorunlarını gerektirir. Daha önce hiç yapmadıysanız, bu zor olabilir.
2. Bir başarısızlık noktası. Bir servis kesintisi varsa, tüm müşteriler etkilenir. Kod bu şekilde kullanılmadığında, risk daha düşük olabilir (bunu hafifletmenin yolları olsa da).
3. Sürüm oluşturma yapmak zor olabilir. Bir hizmeti kullanarak bir uygulamanız varsa, dağıtma arayüz değişiklikleri ikisi arasında aynı anda yapılabilir. Artık birden fazla müşteriniz olduğunda, kimin V1’de, kimin V2’de olduğunu ve V1’in kaldırılmasını koordine etmelisiniz (herkesin V2’ye güncellendiğini bildikten sonra).

Asıl nokta, sistem servisinizi yönlendirmek için her zaman bir smaç değil. Tecrübelerime göre bu genellikle iyi bir fikirdir (uygulamaları bu şekilde yapılandırma eğilimindeyim), ancak bu otomatik bir karar değil. Günün sonunda artıları ve eksileri tartmanız ve durumunuza uygun kararı vermeniz gerekir.

Gördüğüm çoğu Servis Katmanı tam bir karışıklık. Hizmetlerin birçok farklı yöntemi olma eğilimindedir, 1500 LOC nadir değildir. Farklı yöntemlerin ortak hiçbir yanı yoktur, ancak kodu paylaşırlar. Bu, yüksek kavrama , düşük uyum ile sonuçlanır . Aynı zamanda OCP'yi de ihlal eder , çünkü her yeni bir işlem gerektiğinde, kod tabanını genişletmek yerine kodu değiştirmeniz gerekir. İyi yapılandırılmış bir servis katmanı teorik olarak mümkündür, ancak pratikte hiç görmedim.

CQRS bu problemleri çözer ve bu prosedürel servis katmanlarından birini yaratmanızı önler.

Bir arayüz eklemek (servis katmanı bir arayüz türüdür) zaman alır. İyi bir şey tasarlamak ve test etmek için çok zaman alır. İlk denemede doğru yapmak çok önemlidir, çünkü daha sonra değiştirmek tüm müşterileri kırar. Ayrıca, biraz farklı ihtiyaçları olan ikinci bir müşteriniz olana kadar muhtemelen bu arayüzde ne olması gerektiğini bilmeyeceğinizi düşünün. Bir hizmeti sürdürmek kendi içinde hiç bitmeyen bir projedir.

Çoğu kuruluşta, işletme sponsorunuza gidip onlara şu soruyu sorarsanız, "Bütçeniz ile geliştirdiğimiz bu sistemin diğer bölümlerden (yeniden) faydalanmasını ister misiniz?" sana gülecekler. İlk önce işletme sponsorunuz için çalışmasını sağlayın, daha sonra bu kodu tekrar kullanarak etrafınızda titremeye başlayın (bölümünüzün kendi zamanında).

Aslında, bugün yazdığınız işlevselliğin birden fazla farklı servis istemcisi tarafından tekrar kullanılacağını biliyorsanız, o zaman ilk günden itibaren bir servis katmanı tasarlamayı düşünün. Emin değilseniz veya zaten projede çok fazla bilinmeyen varsa, önce basit bir işlem yapın ve zamanınız ve bütçeniz varsa daha sonra hizmete ve müşteriye ayırın. Çalışan bir sisteme başladığınızda ilk kez denemede servis arayüzünü elde etmek çok daha kolaydır.

Not: Eğer Java'da çalışıyorsanız, Joshua Bloch'un efektif Java kitabı boyunca çok sayıda harika arayüz önerileri var.

Size katılıyorum. Tek bir kullanıcı arayüzü kullanıyorsanız, bir katman daha eklemenize gerek yoktur.

DAL, BL ve UI / Controller bir uygulamayı tasarlamak için iyi bir kombinasyondur. Tek bir UI ile gitmeyi planlıyorsanız, ekstra bir katman hazırlamaya gerek yoktur. Uygulamaya 1 kat daha eklenmesi yalnızca geliştirme çabalarını / süresini artırır.

Başka bir schenerio, uygulamanızda birden fazla kullanıcı arayüzü kullanmaktır, bu durumda kullanıcı arayüzlerini ele almak için bir servis katmanı olması iyidir.

Yığın Taşması: Servis katmanı modeli üzerinde tartışma

BL'nizin servis katmanınız olduğuna itiraz ediyorum. İş mantığınızın oturduğu merkezi bir yer. Bu, mantık gerektiren herhangi bir şey tarafından kullanılabilecek bir DLL olmalıdır. Daha sonra, uygulamanız farklı kullanıcı arayüzlerine sahipse, bunun üzerine bir web api katmanı koyabilirsiniz.