ควรตรวจสอบความถูกต้องของเลเยอร์ใด


18

ฉันกำลังสร้าง Rest API โดยใช้ Spring Boot และฉันกำลังใช้การตรวจสอบความถูกต้องของไฮเบอร์เนตเพื่อตรวจสอบอินพุตคำขอ

แต่ฉันยังต้องการการตรวจสอบความถูกต้องประเภทอื่นเช่นเมื่ออัปเดตข้อมูลจำเป็นต้องตรวจสอบหากไม่มีรหัส บริษัท ฉันต้องการส่งข้อยกเว้นที่กำหนดเอง

การตรวจสอบความถูกต้องนี้ควรอยู่ที่ชั้นบริการหรือชั้นควบคุมหรือไม่

ชั้นบริการ:

 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);
}

เลเยอร์ควบคุม:

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);
}

คำตอบ:


8

ทั้งเลเยอร์คอนโทรลเลอร์และเลเยอร์บริการเปิดเผยอินเตอร์เฟสบางอย่าง อินเทอร์เฟซกำหนดสัญญาในการใช้อินเทอร์เฟซ สัญญามักจะหมายถึงข้อโต้แย้งใด (และประเภทและค่า) ที่คาดว่าจะมีข้อยกเว้นซึ่งสามารถโยนซึ่งผลข้างเคียงที่ถูกสร้างขึ้น ฯลฯ

ตอนนี้การตรวจสอบของคุณคือการบังคับใช้สัญญาการควบคุมคอนโทรลเลอร์ () วิธีการและวิธีการปรับปรุงเลเยอร์บริการ () ทั้งคู่มีสัญญาที่คล้ายกันมากดังนั้นจึงเป็นเรื่องธรรมดาถ้าการตรวจสอบ (การบังคับใช้สัญญา) เป็นเรื่องธรรมดา

วิธีหนึ่งที่เป็นไปได้ในการทำเช่นนั้นคือการแยกการตรวจสอบความถูกต้องของสัญญานี้และเรียกมันว่าทั้งสองเลเยอร์ นี่เป็นเรื่องที่ชัดเจนที่สุด - แต่ละคลาส / วิธีการบังคับใช้สัญญาของตนเอง แต่มักจะไม่ได้ผลเนื่องจากประสิทธิภาพ (การเข้าถึงฐานข้อมูล) หรือเหตุผลอื่น ๆ

ความเป็นไปได้อื่น ๆ คือการมอบหมายการตรวจสอบนี้ให้กับชั้นบริการในขณะที่กำหนดพฤติกรรมอย่างชัดเจนในกรณีที่การตรวจสอบล้มเหลวในสัญญาบริการชั้น โดยทั่วไปชั้นบริการจะส่งกลับข้อผิดพลาดในการตรวจสอบความถูกต้องทั่วไป (หรือข้อยกเว้นการโยน) และชั้นควบคุมจะต้องการตอบสนองต่อข้อผิดพลาดบางอย่าง - ในกรณีนี้เราจะส่งกลับ 400 คำขอไม่ถูกต้อง

ในการออกแบบนี้มีอันตรายจากการมีเพศสัมพันธ์มากเกินไประหว่างตรรกะทางธุรกิจในชั้นบริการ (ซึ่งควรจะค่อนข้างทั่วไป) และตัวควบคุม (ซึ่งจัดการตรรกะการรวม)

อย่างไรก็ตามนี่เป็นคำถามที่ถกเถียงกันมากและ 100 คนจะตอบด้วย 100 คำตอบ นี่เป็นเพียงความรับผิดชอบของฉัน


1

ควรตรวจสอบข้อมูลเข้าในเลเยอร์บริการ

และ "ไม่พบ id" เป็นเงื่อนไขข้อผิดพลาดเชิงตรรกะ ดังนั้นควรโยนจากเลเยอร์ควบคุม

สิ่งนี้ขึ้นอยู่กับการออกแบบ / เลเยอร์ของคุณอีกครั้ง
สิ่งที่ชั้นบริการควรจะทำและสิ่งที่คาดหวังจากชั้นควบคุม


คำตอบไม่ควรค้นหาคำอธิบายเพิ่มเติมจากคำถาม หากคำถามนั้นต้องการการชี้แจงก็ควรให้ความเห็นและอาจตั้งค่าสถานะเพื่อปิดหากไม่ชัดเจนเกินไป ใช่ฉันรู้ว่าคุณไม่มีชื่อเสียงในการกระทำเหล่านั้น

"การตรวจสอบอินพุต" ไม่ชัดเจน ตัวอย่างเช่นฉันอาจวางแอตทริบิวต์ที่จำเป็นในเขตข้อมูลเพื่อระบุว่าจะต้องกรอก แต่ฉันอาจวางแอตทริบิวต์แบบกำหนดเองที่ซับซ้อนที่ตรวจสอบตัวอย่างเช่นค่าเขตข้อมูลหนึ่งมีค่ามากกว่าค่าอื่น IMHO การเปรียบเทียบการตรวจสอบความถูกต้อง "มีกลิ่น" ของชั้นบริการธุรกิจมากกว่าชั้นควบคุม
JustAMartin

1

การตรวจสอบความจำ Hibernate เป็นการตรวจสอบความสมบูรณ์ของข้อมูล เพื่อหลีกเลี่ยง RuntimeExceptions จาก bbdd พวกเขาจะสวยมากการตรวจสอบเดียวกับที่คุณควรควบคุมด้วยข้อ จำกัด เนื่องจากมีเพียงเลเยอร์ธุรกิจเท่านั้นที่จะป้อนเลเยอร์การคงอยู่คุณอาจ (หรือไม่ขึ้นอยู่กับคุณ) วางใจในความถูกต้องของข้อมูลที่มาจากเลเยอร์ธุรกิจของคุณ

ฉันไม่ได้ทำการตรวจสอบใน DAO ฉันคาดว่าข้อมูลที่ถูกต้องจากชั้นบน ในกรณีที่มีข้อผิดพลาดฉันมอบหมายให้ผู้ดูแลความรับผิดชอบในการรับรู้เนื้อหา

จากนั้นตรวจสอบความถูกต้องที่ชั้นธุรกิจ ทั้งหมดการตรวจสอบธุรกิจที่มุ่งเน้นในการรักษาการเชื่อมโยงกันของข้อมูลที่ไม่สมบูรณ์ของมัน

ในที่สุดฉันก็ทำการตรวจสอบก่อนหน้านี้ในชั้นควบคุม ผู้ที่เกี่ยวข้องกับเลเยอร์ดังกล่าวเท่านั้น

คุณจะเห็นในไม่ช้าว่าการตรวจสอบความถูกต้องมีจุดประสงค์เพื่อฝังที่ชั้นธุรกิจ การควบคุม id ที่พบมากที่สุด อันนี้สามารถนำไปใช้ได้ทั้งสองเลเยอร์ หากคุณคาดว่าจะมีตัวควบคุมหรือลูกค้าจำนวนมากที่ใช้เลเยอร์ธุรกิจของคุณแล้วแทนที่จะทำการตรวจสอบซ้ำซ้ำทุกที่มันจะเป็นตัวเลือกที่ยอดเยี่ยมที่จะนำไปสู่ชั้นธุรกิจ

บางครั้งผู้ควบคุมมีกฎและเงื่อนไขของตัวเองที่จะไม่ทำซ้ำในส่วนอื่น ๆ จากนั้นจึงเป็นผู้สมัครที่จะใส่ในตัวควบคุมดังกล่าว

คิดเกี่ยวกับสิ่งที่คุณกำลังตรวจสอบและถ้าคุณต้องการที่จะใช้มันสำหรับทุกคนไม่ว่าอะไร หรือหากเป็นการตรวจสอบตามบริบท ("ฉันกำลังตรวจสอบความถูกต้องบางอย่างที่เกิดขึ้นเฉพาะส่วนควบคุม / มุมมองด้านหน้า)


0

ในร้านค้าชวาของเราเราได้ทำการแยกการตรวจสอบวิดเจ็ตเว็บอย่างตั้งใจออกเป็นสามส่วน

  1. การจัดรูปแบบพื้นฐาน - ตัวเลขต้องเป็นตัวเลข วันที่จะต้องเป็นวันที่ที่ถูกต้องเป็นต้นโดยปกติการตรวจสอบนี้มาโดยไม่เสียค่าใช้จ่าย - กรอบงานเว็บจะทำเพื่อคุณเมื่อเชื่อมโยงเนื้อหาวิดเจ็ตกับโมเดล
  2. การตรวจสอบวิดเจ็ตเดี่ยว - วันที่ต้องเป็นวันที่ในอดีต จำนวนเต็มต้องอยู่ระหว่าง 1 ถึง 100 customerId ต้องมีอยู่ในฐานข้อมูลเป็นต้นส่วนใหญ่จะเป็นของเลเยอร์คอนโทรลเลอร์ในกรณีส่วนใหญ่ แต่อาจต้องการการสนับสนุนจากแหล่งเก็บข้อมูล
  3. การตรวจสอบข้ามวิดเจ็ต - วันที่ชำระเงินจะต้องอยู่หลังวันที่เช็คอิน; วันที่ตายไม่สามารถมาก่อนวันเดือนปีเกิดเป็นต้นนี่เป็นการตรวจสอบความถูกต้องตามกฎเกณฑ์ทางธุรกิจ เรามักจะใส่สิ่งนี้ลงในเลเยอร์ตัวควบคุมเช่นกัน แต่คุณอาจต้องการเปลี่ยนมันให้เป็นตัวตรวจสอบความถูกต้องทางธุรกิจเพื่อให้สามารถนำกลับมาใช้ใหม่ได้

หากเลเยอร์ 1 ล้มเหลวเราจะไม่ตรวจสอบ 2 หรือ 3 ในทำนองเดียวกันถ้า 1 ประสบความสำเร็จและ 2 ล้มเหลวที่เราไม่ได้ทำ 3 สิ่งนี้จะหยุดการสร้างข้อความแสดงข้อผิดพลาดปลอม

คุณกำลังถามเกี่ยวกับค่าในการเรียกใช้ REST แทนเนื้อหาวิดเจ็ต แต่ใช้หลักการเดียวกัน


-1

aproach ทดสอบขับเคลื่อนแรเงาแสงนี้ ,, หลังจากทั้งหมดไม่มีตัวควบคุมและคุณต้องเลือกตัวเลือกอื่น เห็นได้ชัดว่ากฎธุรกิจรถบัสควรอยู่ในที่เดียวและนี่เป็นข้อ จำกัด อีกประการหนึ่งในการตัดสินใจของคุณ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.