लेनदेन स्क्रिप्ट Antipattern है?

Question

वैसे भी NoSQL डेटाबेस के साथ लेनदेन स्क्रिप्ट के बारे में एक समान विषय है, लेकिन यह सामान्य रूप से पैटर्न के बारे में है। ट्रांजैक्शन स्क्रिप्ट के बारे में मुझे जो मिलता है, उससे ऑब्जेक्ट उन्मुख नहीं है। इस तथ्य के बावजूद यह मूल रूप से प्रक्रियात्मक कोड है कि यह अपने कोड की प्रत्येक पंक्ति में वस्तुओं का उपयोग कर सकता है।

बेहतर समाधान एक डोमेन मॉडल का उपयोग करना है, या तो सक्रिय रिकॉर्ड या कार्य/पहचान मानचित्र/आलसी लोड/क्वेरी ऑब्जेक्ट और इस तरह की इकाई के साथ डेटा मैपर के साथ। लेनदेन स्क्रिप्ट का उपयोग करना आसान हो सकता है, लेकिन यह वास्तव में प्रक्रियात्मक प्रोग्रामिंग है और इसलिए वस्तु उन्मुख दुनिया में एक एंटीपाटर माना जाना चाहिए।

आपको क्या लगता है? क्या आप लेन-देन स्क्रिप्ट के साथ एंटीपाटरन से सहमत हैं? या क्या आपके पास वास्तव में एक लेनदेन स्क्रिप्ट तैयार करने का एक तरीका है जो छिपाने में प्रक्रियात्मक के बजाय ऑब्जेक्ट उन्मुख है? मुझे संदेह है कि यह संभव है हालांकि।

Answer 1

लेनदेन स्क्रिप्ट निश्चित रूप से विरोधी-पैटर्न नहीं है।

लेनदेन स्क्रिप्ट के बारे में मुझे जो मिलता है, उससे ऑब्जेक्ट उन्मुख नहीं है।

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

या - के रूप में Fowler लिखते हैं:

जब उपयोग करने के लिए यह

लेन-देन स्क्रिप्ट की महिमा अपनी सादगी है। तर्क को व्यवस्थित करना इस तरह के अनुप्रयोगों के लिए प्राकृतिक है, केवल तर्क की एक छोटी राशि के साथ, और इसमें प्रदर्शन या समझ में बहुत कम ओवरहेड शामिल है।

एंटी-पैटर्न जिसे आप सोच सकते हैं उसे Anemic Domain Model कहा जाता है। यह मामला है जब आप इरादा और सोचें आप एक डोमेन मॉडल बना रहे हैं - क्योंकि आपकी समस्या डोमेन इसके लिए काफी जटिल है, लेकिन वास्तव में एक लेनदेन स्क्रिप्ट में समाप्त होता है - खराब कोड व्यवस्थित/कमजोर होने के कारण ओओ कौशल।

Answer 2

यह विरोधी पैटर्न नहीं है। वास्तव में, अधिकांश एंटरप्राइज़ एप्लिकेशन (मैंने जो देखा है) लेनदेन स्क्रिप्ट का उपयोग करते हैं, न कि समृद्ध डोमेन मॉडल पैटर्न।

सक्रिय रिकॉर्ड पैटर्न जो आपने उल्लेख किया है वह केवल तब आसान है जब आप लगातार स्टोर एग्रीगेट्स (आरडीबीएमएस टेबल) में डोमेन इकाइयों के मैपिंग के लिए सरल हैं।

डेटा मैपर ओआरएम (हाइबरनेट और दोस्तों) जैसा कुछ है। यदि आपका व्यवसाय तर्क डोमेन इकाइयों के भीतर रहता है, तो इन इकाइयों को स्वयं को बदलना होगा। मेरी राय में, यह जोड़ तर्क जो राज्य को बदलता है (जो आप ओआरएम का उपयोग करते समय निहित है) राज्य के साथ ही।बाहर से अपने डोमेन मॉडल को देखना आसान है और अपने व्यवसाय तर्क सेवाओं (लेनदेन स्क्रिप्ट) में डाल दें। साथ ही, यदि आपका व्यवसाय तर्क मात्रा बड़ी है, तो डोमेन इकाइयों में बिखरे हुए प्रासंगिक कोड को ढूंढना कठिन होता है (ऐसा लगता है कि आपकी लेन-देन स्क्रिप्ट एक साथ मिश्रित हैं)।

लेकिन आपको पूरी तरह से प्रक्रियात्मक दृष्टिकोण के साथ समाप्त होने की आवश्यकता नहीं है क्योंकि आप अपनी सेवाओं को स्वयं निहित अत्यधिक प्रक्रियात्मक कंटेनर में विघटित कर सकते हैं (और चाहिए)।