अमूर्त CRUD रिपॉजिटरी से कंट्रोलर तक: आप स्प्रिंग + जेनरिक के साथ और क्या कर सकते हैं

हाल ही में, एक सहकर्मी लेख Habré पर भड़क गया, जिसने जेनरिक और स्प्रिंग क्षमताओं के संयोजन के लिए एक दिलचस्प दृष्टिकोण का वर्णन किया। उसने मुझे एक दृष्टिकोण याद दिलाया जिसका उपयोग मैं माइक्रोसॉफ़्ट लिखने के लिए करता हूँ, और मैंने इसे पाठकों के साथ साझा करने का निर्णय लिया।



आउटपुट पर, हमें एक ट्रांसपोर्ट सिस्टम मिलता है, जिसे जोड़ने के लिए एक नई इकाई के लिए हमें रिपॉजिटरी-सर्विस-कंट्रोलर बंडल के प्रत्येक तत्व में एक बीन को इनिशियलाइज़ करने की आवश्यकता होगी।

तुरंत संसाधन ।
शाखा, जैसा कि मैं नहीं करता: standart_version ।
लेख में वर्णित दृष्टिकोण abstract_version शाखा में है।

मैंने JPA, Web, और H2 चौखटे को जोड़ते हुए स्प्रिंग अनिलिग्री के माध्यम से एक प्रोजेक्ट रखा। ग्रेड, स्प्रिंग बूट 2.0.5। यह काफी पर्याप्त होगा।



शुरू करने के लिए, नियंत्रक से भंडार तक परिवहन के क्लासिक संस्करण पर विचार करें और इसके विपरीत, किसी भी अतिरिक्त तर्क से रहित। यदि आप दृष्टिकोण के सार पर जाना चाहते हैं, तो नीचे दिए गए सार संस्करण पर स्क्रॉल करें। लेकिन, फिर भी, मैं पूरा लेख पढ़ने की सलाह देता हूं।

क्लासिक संस्करण।

उदाहरण के संसाधन उनके लिए कई संस्थाएँ और विधियाँ प्रदान करते हैं, लेकिन लेख में हमें केवल एक उपयोगकर्ता इकाई और केवल एक सेव () विधि है, जिसे हम रिपॉजिटरी से सेवा के माध्यम से नियंत्रक तक खींचेंगे। संसाधनों में, उनमें से 7 हैं, लेकिन सामान्य तौर पर स्प्रिंग सीआरयूडी / जेपीए रिपोजिटरी आपको बचत / हटाने / हटाने के एक दर्जन तरीकों का उपयोग करने की अनुमति देता है, साथ ही आप उपयोग कर सकते हैं, उदाहरण के लिए, कुछ सार्वभौमिक । इसके अलावा, हम इस तरह की आवश्यक चीजों से विचलित नहीं होंगे, जैसे कि सत्यापन, डोपिंग वगैरह। आप इसे स्वयं जोड़ सकते हैं या हैबर के अन्य लेखों में अध्ययन कर सकते हैं।

डोमेन:

@Entity public class User implements Serializable { private Long id; private String name; private String phone; @Id @GeneratedValue public Long getId() { return id; } public void setId(Long id) { this.id = id; } @Column(nullable = false) public String getName() { return name; } public void setName(String name) { this.name = name; } @Column public String getPhone() { return phone; } public void setPhone(String phone) { this.phone = phone; } //equals, hashcode, toString } 

भंडार:

 @Repository public interface UserRepository extends CrudRepository<User, Long> { } 

सेवा:

 public interface UserService { Optional<User> save(User user); } 

सेवा (कार्यान्वयन):

 @Service public class UserServiceImpl implements UserService { private final UserRepository userRepository; @Autowired public UserServiceImpl(UserRepository userRepository) { this.userRepository = userRepository; } @Override public Optional<User> save(User user) { return Optional.of(userRepository.save(user)); } } 

नियंत्रक:

 @RestController @RequestMapping("/user") public class UserController { private final UserService service; @Autowired public UserController(UserService service) { this.service = service; } @PostMapping public ResponseEntity<User> save(@RequestBody User user) { return service.save(user).map(u -> new ResponseEntity<>(u, HttpStatus.OK)) .orElseThrow(() -> new UserException( String.format(ErrorType.USER_NOT_SAVED.getDescription(), user.toString()) )); } } 

हमें आश्रित वर्गों का एक निश्चित समूह मिला है जो हमें CRUD स्तर पर उपयोगकर्ता इकाई के संचालन में मदद करेगा। हमारे उदाहरण में, यह एक विधि है, संसाधनों में अधिक हैं। लेखन परतों के सभी अमूर्त संस्करण में इसे प्रस्तुत नहीं किया गया है।

मान लीजिए, हमें एक और इकाई जोड़ने की आवश्यकता है, कहते हैं, कार। हमने एक-दूसरे को संस्थाओं के स्तर पर पैसा नहीं दिया (यदि आप चाहें, तो आप इसे मैप कर सकते हैं)।

सबसे पहले, एक इकाई बनाएँ।

 @Entity public class Car implements Serializable { private Long id; private String brand; private String model; @Id @GeneratedValue public Long getId() { return id; } public void setId(Long id) { this.id = id; } //, , equals, hashcode, toString } 

फिर एक भंडार बनाएँ।

 public interface CarRepository extends CrudRepository<Car, Long> { } 

फिर सेवा ...

 public interface CarService { Optional<Car> save(Car car); List<Car> saveAll(List<Car> cars); Optional<Car> update(Car car); Optional<Car> get(Long id); List<Car> getAll(); Boolean deleteById(Long id); Boolean deleteAll(); } 

फिर सेवा का कार्यान्वयन ....... नियंत्रक ...........

हां, आप उपयोगकर्ता वर्ग से एक ही तरीके (वे यहां सार्वभौमिक हैं) को कॉपी और पेस्ट कर सकते हैं, फिर उपयोगकर्ता को कार में बदल सकते हैं, फिर कार्यान्वयन के साथ, नियंत्रक के साथ एक ही कर सकते हैं, फिर अगली इकाई लाइन में है, और वहां वे पहले से ही अधिक से अधिक दिखते हैं ... आमतौर पर आप दूसरे से थक जाते हैं, दर्जनों संस्थाओं के लिए एक सेवा वास्तुकला का निर्माण (कॉपी-पेस्ट, इकाई का नाम बदलकर, कहीं गलत, कहीं सील ...) किसी भी नीरस काम का कारण बनता है। अपने अवकाश पर किसी तरह बीस संस्थाओं को निर्धारित करने की कोशिश करें और आप समझ जाएंगे कि मेरा क्या मतलब है।

और इसलिए, एक बिंदु पर, जब मुझे सिर्फ जेनरिक और विशिष्ट मापदंडों में दिलचस्पी थी, तो यह मुझ पर हावी हो गया कि इस प्रक्रिया को बहुत कम दिनचर्या बनाया जा सकता है।

तो, विशिष्ट मापदंडों के आधार पर सार।

इस दृष्टिकोण का अर्थ सभी तर्कों को अमूर्तता में ले जाना है, अमूर्त को इंटरफ़ेस के विशिष्ट मापदंडों से बांधना और अन्य डिब्बे को डिब्बे में इंजेक्ट करना है। और वह यह है। फलियों में कोई तर्क नहीं। केवल अन्य बीन्स का एक इंजेक्शन। इस दृष्टिकोण में एक बार आर्किटेक्चर और लॉजिक लिखना और नई संस्थाओं को जोड़ने पर इसे डुप्लिकेट नहीं करना शामिल है।

चलो हमारे अमूर्त की आधारशिला से शुरू करते हैं - एक अमूर्त इकाई। यह उससे है कि अमूर्त निर्भरता की श्रृंखला शुरू होगी, जो सेवा के ढांचे के रूप में काम करेगी।

सभी संस्थाओं में कम से कम एक सामान्य क्षेत्र (आमतौर पर अधिक) होता है। यह आईडी है। हम इस क्षेत्र को एक अलग अमूर्त इकाई में ले जाते हैं और उपयोगकर्ता और कार को इनहेरिट करते हैं।

AbstractEntity:

 @MappedSuperclass public abstract class AbstractEntity implements Serializable { private Long id; @Id @GeneratedValue public Long getId() { return id; } public void setId(Long id) { this.id = id; } } 

@MappedSuperclass एनोटेशन के साथ अमूर्त को चिह्नित करना याद रखें - हाइबरनेट को यह भी पता होना चाहिए कि यह एक अमूर्त है।

उपयोगकर्ता:

 @Entity public class User extends AbstractEntity { private String name; private String phone; //... } 

कार के साथ, तदनुसार, वही।

प्रत्येक परत में, डिब्बे के अलावा, हमारे पास विशिष्ट मापदंडों के साथ एक इंटरफ़ेस और तर्क के साथ एक सार वर्ग होगा। रिपॉजिटरी के अलावा - स्प्रिंग डेटा जेपीए की बारीकियों के लिए धन्यवाद, यहां सब कुछ बहुत सरल होगा।

रिपॉजिटरी में पहली चीज जो हमें चाहिए वह एक साझा रिपॉजिटरी है।

CommonRepository:

 @NoRepositoryBean public interface CommonRepository<E extends AbstractEntity> extends CrudRepository<E, Long> { } 

इस रिपॉजिटरी में, हम पूरी श्रृंखला के लिए सामान्य नियम निर्धारित करते हैं: इसमें भाग लेने वाली सभी संस्थाएं सार से विरासत में मिलेंगी। अगला, प्रत्येक इकाई के लिए, हमें अपना रिपॉजिटरी-इंटरफ़ेस लिखना होगा, जिसमें हम संकेत देते हैं कि यह रिपॉजिटरी-सर्विस-कंट्रोलर चेन किस इकाई के साथ काम करेगी।

UserRepository:

 @Repository public interface UserRepository extends CommonRepository<User> { } 

स्प्रिंग डेटा जेपीए की विशेषताओं के लिए धन्यवाद, रिपॉजिटरी सेटअप यहां समाप्त होता है - सब कुछ उसी तरह काम करेगा। इसके बाद सर्विस आती है। हमें एक सामान्य इंटरफ़ेस, अमूर्तता और बीन बनाने की आवश्यकता है।

CommonService:

 public interface CommonService<E extends AbstractEntity> { { Optional<E> save(E entity); //-     } 

AbstractService:

 public abstract class AbstractService<E extends AbstractEntity, R extends CommonRepository<E>> implements CommonService<E> { protected final R repository; @Autowired public AbstractService(R repository) { this.repository = repository; } // ,    } 

यहां हम सभी तरीकों को फिर से परिभाषित करते हैं, और भविष्य के भंडार के लिए एक मानकीकृत निर्माणकर्ता भी बनाते हैं, जिसे हम बीन में फिर से परिभाषित करते हैं। इस प्रकार, हम पहले से ही एक भंडार का उपयोग कर रहे हैं जिसे हमने अभी तक परिभाषित नहीं किया है। हमें अभी तक नहीं पता है कि इस अमूर्त में किस इकाई को संसाधित किया जाएगा और हमें किस भंडार की आवश्यकता होगी।

UserService:

 @Service public class UserService extends AbstractService<User, UserRepository> { public UserService(UserRepository repository) { super(repository); } } 

बिन में, हम अंतिम काम करते हैं - हम स्पष्ट रूप से उस रिपॉजिटरी को परिभाषित करते हैं जिसकी हमें ज़रूरत है, जिसे तब अमूर्त कंस्ट्रक्टर में कहा जाता है। और वह यह है।

इंटरफ़ेस और अमूर्तता का उपयोग करते हुए, हमने एक राजमार्ग बनाया, जिसके माध्यम से हम सभी संस्थाओं को चलाएंगे। बिन में, हम राजमार्ग पर डिनोमिनेशन लाते हैं, जिसके माध्यम से हम उस इकाई को प्रदर्शित करेंगे जिसकी हमें राजमार्ग पर आवश्यकता है।

नियंत्रक एक ही सिद्धांत पर बनाया गया है: इंटरफ़ेस, अमूर्त, बिन।

CommonController:

 public interface CommonController<E extends AbstractEntity> { @PostMapping ResponseEntity<E> save(@RequestBody E entity); //  } 

AbstractController:

 public abstract class AbstractController<E extends AbstractEntity, S extends CommonService<E>> implements CommonController<E> { private final S service; @Autowired protected AbstractController(S service) { this.service = service; } @Override public ResponseEntity<E> save(@RequestBody E entity) { return service.save(entity).map(ResponseEntity::ok) .orElseThrow(() -> new SampleException( String.format(ErrorType.ENTITY_NOT_SAVED.getDescription(), entity.toString()) )); } //  } 

UserController:

 @RestController @RequestMapping("/user") public class UserController extends AbstractController<User, UserService> { public UserController(UserService service) { super(service); } } 

यह पूरी संरचना है। यह एक बार लिखा गया है।

आगे क्या है?

और अब कल्पना करते हैं कि हमारे पास एक नई इकाई है जो हमें पहले से ही AbstractEntity से विरासत में मिली है, और हमें इसके लिए एक ही श्रृंखला लिखने की आवश्यकता है। इसमें हमें एक मिनट लगेगा। और कोई कॉपी-पेस्ट और करेक्शन नहीं।

AbstractEntity कार से पहले से ही विरासत में मिला है।

CarRepository:

 @Repository public interface CarRepository extends CommonRepository<Car> { } 

CarService:

 @Service public class CarService extends AbstractService<Car, CarRepository> { public CarService(CarRepository repository) { super(repository); } } 

CarController:

 @RestController @RequestMapping("/car") public class CarController extends AbstractController<Car, CarService> { public CarController(CarService service) { super(service); } } 

जैसा कि हम देख सकते हैं, एक ही तर्क को कॉपी करने में केवल बीन जोड़ना शामिल है। मापदंडों और हस्ताक्षरों के परिवर्तन के साथ प्रत्येक बिन में तर्क को फिर से लिखने की आवश्यकता नहीं है। वे एक बार लिखे गए हैं और प्रत्येक बाद के मामले में काम करते हैं।

निष्कर्ष

बेशक, उदाहरण एक प्रकार की गोलाकार स्थिति का वर्णन करता है जिसमें प्रत्येक इकाई के लिए CRUD में एक ही तर्क होता है। ऐसा नहीं होता है - आपको अभी भी बिन में कुछ तरीकों को फिर से परिभाषित करना होगा या नए जोड़ना होगा। लेकिन यह इकाई प्रसंस्करण की विशिष्ट आवश्यकताओं से आएगा। खैर, अगर सीआरयूडी विधियों की कुल संख्या का 60 प्रतिशत अमूर्तता में रहेगा। और यह एक अच्छा परिणाम होगा, क्योंकि जितना अधिक हम अनावश्यक कोड को मैन्युअल रूप से उत्पन्न करते हैं, उतना ही अधिक समय हम नीरस काम पर खर्च करते हैं और त्रुटियों या टाइपो का जोखिम अधिक होता है।

मुझे उम्मीद है कि लेख उपयोगी था, आपके ध्यान के लिए धन्यवाद।

युपीडी।

प्रस्ताव के लिए धन्यवाद, एलेक्सेन्डी निर्माण में बीन की आरंभीकरण प्राप्त करने में कामयाब रहा और इस तरह दृष्टिकोण में काफी सुधार हुआ। यदि आप देखते हैं कि आप उदाहरण में और कैसे सुधार कर सकते हैं, तो टिप्पणियों में लिखें, और शायद आपके सुझाव प्रस्तुत किए जाएंगे।