Doğrulama hangi katmana yerleştirilmelidir?

Spring Boot kullanarak bir Rest API oluşturuyorum ve istek girişlerini doğrulamak için Hazırda Bekletme Doğrulaması kullanıyorum.

Ancak, başka tür doğrulamalara da ihtiyacım var, örneğin güncelleme verilerinin kontrol edilmesi gerektiğinde, şirket kimliği yoksa özel bir istisna atmak istiyorum.

Bu doğrulama hizmet katmanında mı yoksa denetleyici katmanında mı bulunmalı?

Hizmet Katmanı:

 public Company update(Company entity) {
    if (entity.getId() == null || repository.findOne(entity.getId()) == null) {
        throw new ResourceNotFoundException("can not update un existence data with id : " 
            + entity.getId());
    }
    return repository.saveAndFlush(entity);
}

Denetleyici Katmanı:

public HttpEntity<CompanyResource> update(@Valid @RequestBody Company companyRequest) {
    Company company = companyService.getById(companyRequest.getId());
    Precondition.checkDataFound(company, 
        "Can't not find data with id : " + companyRequest.getId());

    // TODO : extract ignore properties to constant

    BeanUtils.copyProperties(companyRequest, company, "createdBy", "createdDate",
            "updatedBy", "updatedDate", "version", "markForDelete");
    Company updatedCompany = companyService.update(company);
    CompanyResource companyResource = companyAssembler.toResource(updatedCompany);
    return new ResponseEntity<CompanyResource>(companyResource, HttpStatus.OK);
}

Hem denetleyici katmanı hem de hizmet katmanı belirli arabirimleri ortaya çıkarır. Arayüzler, arayüzün nasıl kullanılması gerektiğine dair sözleşmeleri tanımlar. Sözleşme genellikle hangi argümanların (ve türlerinin ve değerlerinin) beklendiği, hangi istisnaların atılabileceği, hangi yan etkilerin yaratıldığı vb.

Şimdi, doğrulamanız esasen denetleyici update () yöntemi ve hizmet katmanı update () yöntemi sözleşmesinin uygulanmasıdır. Her ikisinin de çok benzer bir sözleşmesi vardır, bu yüzden validasyonun (sözleşmenin uygulanması) da yaygın olması doğal olacaktır.

Bunu yapmanın olası bir yolu, bu sözleşmenin validasyonunu ayırmak ve her iki katmanda da çağırmaktır. Bu genellikle en açık olanıdır - her sınıf / yöntem kendi sözleşmelerini uygular, ancak performans (veritabanına erişme) veya diğer nedenlerden dolayı genellikle pratik değildir.

Diğer olasılık, hizmet katmanı sözleşmesinde başarısız doğrulama durumunda davranışı açıkça tanımlarken, bu doğrulamayı hizmet katmanına devretmektir. Hizmet katmanı genellikle bazı genel doğrulama hataları döndürür (veya özel durum atar) ve denetleyici katmanı hataya belirli bir şekilde tepki vermek isteyecektir - bu durumda, gelen isteğin geçersiz olduğunu bildirmek için 400 Hatalı istek döndüreceğiz.

Bu tasarımda, hizmet katmanındaki (oldukça genel olması gereken) iş mantığı ile (entegrasyon mantığını işleyen) denetleyici arasında çok fazla bağlantı tehlikesi vardır.

Her neyse, bu oldukça tartışmalı bir soru ve 100 kişi 100 cevapla cevap verecek. Bu sadece benim almam.

Giriş, servis katmanında kontrol edilmelidir.

Ve "kimlik bulunamıyor" mantıksal hata durumudur. Bu yüzden kontrolör katmanından atılmalıdır.

Bu yine katmanınıza / tasarımınıza bağlıdır.
Bir hizmet katmanının ne yapması gerektiği ve denetleyici katmanından ne beklenmesi gerektiği.

Hazırda bekletme onayları , verilerin bütünlüğü üzerinde yapılan kontrollerdir . Bbdd RuntimeExceptions önlemek için. Kısıtlamalar ile kontrol etmeniz gereken hemen hemen aynı doğrulamalardır . Yalnızca iş katmanının kalıcılık katmanını beslemesi gerektiğinden , iş katmanınızdan gelen verilerin doğruluğuna güvenebilirsiniz (veya etmeyebilirsiniz)

DAO'lara onay vermem. Üst katmanlardan geçerli veri bekliyorum. Bir hata olması durumunda içeriğinin farkında olma sorumluluğunu bbdd'ye devrederim.

Sonra iş katmanında doğrulama geliyor. Tüm iş doğrulamaları , verilerin bütünlüğünü değil tutarlılığını korumaya odaklanmıştır .

Son olarak, kontrol katmanında daha önce onaylamalar yapıyorum. Sadece bu katmanla ilgili olanlar.

Yakında hangi doğrulamaların iş katmanına dahil edilmesi planlandığını göreceksiniz. En yaygın: kimlik kontrolü. Bu, her iki katmana da kolayca uygulanabilir. İş katmanınızı tüketen çok sayıda denetleyici veya müşteriniz olmasını bekliyorsanız, aynı doğrulamayı her yerde tekrarlamak yerine, iş katmanına koymak için mükemmel bir aday olacaktır.

Bazen kontrolörlerin diğer cephelerde çoğaltılmayacak kendi kuralları ve koşulları vardır. O zaman böyle bir denetleyiciye koymak için bir adaydır.

Neyi doğruladığınızı ve ne olursa olsun herkese uygulamak isteyip istemediğinizi düşünün. Veya bağlamsal bir doğrulama ise ("Yalnızca belirli bir kontrol / görünüm cephesinde gerçekleşen bir şeyi onaylıyorum).

Java mağazamızda, web widget doğrulamasını kasıtlı olarak üç ayrı işleme ayırdık.

1. Temel biçimlendirme - sayılar sayı olmalıdır; tarihler geçerli tarihler vb. olmalıdır. Genellikle bu doğrulama ücretsiz olarak gelir. Widget içeriğini modele bağladığınızda web çerçevesi sizin için yapar.
2. Tek widget doğrulaması - tarih geçmişte olmalıdır; bir tam sayı 1 ile 100 arasında olmalıdır; customerId veritabanında vb. bulunmalıdır. Bu, çoğu durumda denetleyici katmanına aittir, ancak veri havuzundan destek alması gerekebilir.
3. Çapraz widget doğrulaması - ödeme tarihi, giriş tarihinden sonra olmalıdır; ölüm tarihi doğum tarihinden önce olamaz. Bu kesinlikle iş kuralı doğrulamasıdır. Bunu denetleyici katmanına da koyma eğilimindeyiz, ancak yeniden kullanılabilmesi için bir iş doğrulayıcıya geçirmek isteyebilirsiniz.

Katman 1 başarısız olursa, 2 veya 3'ü kontrol etmiyoruz. Benzer şekilde 1 başarılı olursa ve 2 başarısız olursa 3 yapmazız. Bu, sahte hata mesajlarının oluşturulmasını durdurur.

Widget içerikleri yerine bir REST çağrısında değerler soruyorsunuz, ancak aynı ilkeler geçerlidir.

Test odaklı yaklaşım bu konuda bir ışık gölgesi ,, sonuçta kontrolör yok ve başka bir seçenek seçmelisiniz. Açıkçası iş kuralları bir yerde olmalıdır ve bu sizin kararınızdaki başka bir kısıtlamadır.