Uygulama hizmet katmanı veritabanı işlevlerini çağırıyor. Kötü mimari mi?

Senaryo:

• Yığın: Java, Bahar, Hazırda Bekletme.
• Model: İstemci-Sunucu Uygulaması.
• Desen: Model-Görünüm-Denetleyici (MVC).

Hizmet Katmanı sınıflarının üç davranışı vardır:

1. Bazı hizmetler, iş kuralı yöntemlerine sahiptir ve kalıcılığı uygulamaya devreder. Sevmek:

   EntityManager.save (entity);

2. Bazı hizmetler bir veritabanı işlevini çağırır (parametreleri iletir)

   CallableStatement cls = con.prepareCall ("{call databaseFunction (args)}");

3. Bazı hizmetlerin her iki davranışı da içeren yöntemleri vardır .

Sorularım:

1. Uygulama hizmetlerinin doğrudan veritabanı işlevlerini çağırmasında herhangi bir sorun var mı? Bu kötü uygulama olarak görülmüyor mu? Böyle bir projeye uygulanabilir bir mimari model ne olurdu?
2. Aynı hizmette davranış karması oluşturmada herhangi bir sorun var mı? İşlemler ve tutarlılık gibi?
3. Bakım durumunda, bu kapsülleme geliştiriciye veritabanındaki işlevleri de değiştirmesi gerektiğini belirsizleştiriyor mu? Bundan nasıl kaçınılır?
4. Bu senaryo dünyadaki diğer uygulamalarda mı meydana geliyor yoksa sadece mimari bir hata mıydı?

Uygulama hizmetlerinin doğrudan veritabanı işlevlerini çağırmasında herhangi bir sorun var mı? Bu kötü uygulama olarak görülmüyor mu?

Bence orada. Uygulama hizmetine veritabanı iç bilgileri hakkında bilgi veriyorsunuz. Hiçbir şekilde veritabanı değiştirme (saklama motorunu değiştirme veya hatta bir alan yeniden adlandırma veya dizini oluşturma) uygulama hizmeti değiştirmenizi gerektirebilir ve bu ihlal SRP .

Böyle bir projeye uygulanabilir bir mimari model ne olurdu?

Aşağıdaki açıklamaya bakınız.

Aynı hizmette davranış karması oluşturmada herhangi bir sorun var mı? İşlemler ve tutarlılık gibi?

Teknik bir sorun olduğuna inanmıyorum, ama mantıklı bir sorun var. Uygulamadaki iki yaklaşımı karıştırmanız, belirsiz, daha az yapılandırılmış, değişikliklere uyum sağlamasını zorlaştırıyor. SRP'yi ihlal etme hakkındaki yukarıdaki yorumlara da bakın.

Bakım durumunda, bu kapsülleme geliştiriciye veritabanındaki işlevleri de değiştirmesi gerektiğini belirsizleştiriyor mu?

Elbette öyle.

Bundan nasıl kaçınılır?

Veritabanıyla doğrudan ayrı bir soyutlama düzeyine çalışan yöntemler ve işlevler yerleştirin (bir DAO katmanı veya basit bir havuz deseni olsun - uygulamanızın karmaşıklığına bağlıdır)

Bu senaryo dünyadaki diğer uygulamalarda mı meydana geliyor yoksa sadece mimari bir hata mıydı?

Bence dünyamızda her şey olur;)

Söylediklerinize göre bir hizmet katmanı var, bu yüzden uygun görünen mimari desen Katmanlı Mimari. Daha fazla referans

Evet, veri erişim katmanı dışında doğrudan veritabanı çağrıları yapmak genellikle kötü bir uygulamadır, bu şekilde iş katmanı yalnızca veritabanının bir soyutlamasına erişir.

Karıştırma davranışlarına gelince, DAO kalıbı veya Depo kalıbı olarak bir tasarım kalıbı kullanmak, sorumlulukların bu kodu geliştirerek temsil edilmesine yardımcı olabilir.

Bir tasarım deseni ve ORM kullanmanın avantajlarından bazıları, kodunuzun okunabilirliğidir, böylece veritabanı erişiminiz değişiyorsa, iş katmanınız çok fazla değişmemelidir.