एक व्यावसायिक वस्तुओं/डेटाबेस पहुंच परत के लिए आर्किटेक्चर

Question

विभिन्न कारणों से, हम एक नई व्यावसायिक वस्तुएं/डेटा संग्रहण पुस्तकालय लिख रहे हैं। इस परत की आवश्यकताओं में से एक व्यापार नियमों के तर्क, और वास्तविक डेटा भंडारण परत को अलग करना है।

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

हम इसे लागू करने के लिए दो मुख्य तरीके हैं, और मैं और सहकर्मी एक मौलिक स्तर पर असहमत हैं जो सही है। मुझे कुछ सलाह चाहिए कि किस पर उपयोग करने के लिए सबसे अच्छा है। मैं जितना संभव हो सके तटस्थ के रूप में अपने विवरणों को रखने की कोशिश करूंगा, क्योंकि मैं यहां कुछ उद्देश्य दृश्य बिंदु ढूंढ रहा हूं।

• व्यावसायिक वस्तुएं मूल कक्षाएं हैं, और डेटा स्टोरेज ऑब्जेक्ट्स व्यवसाय वस्तुओं का उत्तराधिकारी हैं। क्लाइंट कोड डेटा स्टोरेज ऑब्जेक्ट्स से संबंधित है।

  इस मामले में, सामान्य डेटा नियम प्रत्येक डेटा संग्रहण ऑब्जेक्ट द्वारा विरासत में प्राप्त होते हैं, और यह डेटा संग्रहण ऑब्जेक्ट्स है जो सीधे क्लाइंट कोड द्वारा उपयोग किया जाता है।

  यह निहितार्थ है कि क्लाइंट कोड निर्धारित करता है कि किसी दिए गए ऑब्जेक्ट के लिए कौन सी डेटा संग्रहण विधि का उपयोग करना है, क्योंकि इसे उस प्रकार के ऑब्जेक्ट को स्पष्ट रूप से एक उदाहरण घोषित करना है। क्लाइंट कोड को उपयोग किए जा रहे प्रत्येक डेटा संग्रहण प्रकार के लिए कनेक्शन जानकारी स्पष्ट रूप से जानना आवश्यक है।

  यदि कोई डेटा संग्रहण परत किसी दिए गए ऑब्जेक्ट के लिए अलग-अलग कार्यक्षमता लागू करती है, तो क्लाइंट कोड संकलित समय पर इसके बारे में स्पष्ट रूप से जानता है क्योंकि ऑब्जेक्ट अलग दिखता है। यदि डेटा संग्रहण विधि बदल दी गई है, तो क्लाइंट कोड को अद्यतन करना होगा।

• व्यवसाय वस्तुएं डेटा भंडारण वस्तुओं को समाहित करती हैं।

  इस मामले में, व्यावसायिक वस्तुओं का सीधे क्लाइंट एप्लिकेशन द्वारा उपयोग किया जाता है। क्लाइंट एप्लिकेशन बेस लेयर जानकारी के साथ बिजनेस लेयर में गुजरता है। किसी दिए गए ऑब्जेक्ट का उपयोग करने वाले डेटा संग्रहण विधि के बारे में निर्णय व्यावसायिक ऑब्जेक्ट कोड द्वारा किया जाता है। कनेक्शन जानकारी कॉन्फ़िगरेशन फ़ाइल से लिया गया डेटा का एक हिस्सा होगा (क्लाइंट ऐप वास्तव में इसके विवरण के बारे में नहीं जानता/देखभाल नहीं करता है), जो किसी डेटाबेस के लिए एक कनेक्शन स्ट्रिंग हो सकता है, या विभिन्न डेटा संग्रहण प्रकारों के लिए कई टुकड़े कनेक्शन स्ट्रिंग हो सकता है। अतिरिक्त डेटा संग्रहण कनेक्शन प्रकारों को किसी अन्य स्थान से भी पढ़ा जा सकता है - उदाहरण के लिए, डेटाबेस में कॉन्फ़िगरेशन तालिका जो विभिन्न वेब सेवाओं के लिए URL निर्दिष्ट करती है।

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

• व्यावसायिक वस्तुएं बेस क्लास हैं, डेटा स्रोत ऑब्जेक्ट्स व्यावसायिक वस्तुओं से प्राप्त होते हैं। मुख्य रूप से आधार वर्गों के साथ ग्राहक कोड सौदों।

  यह पहली विधि के समान है, लेकिन क्लाइंट कोड बेस बिजनेस ऑब्जेक्ट प्रकारों के चर, और लोड()/बनाएँ()/आदि व्यावसायिक वस्तुओं पर स्थैतिक विधियों की घोषणा करता है, उचित डेटा स्रोत-टाइप की गई वस्तुओं को वापस कर देता है।

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

मैं वहाँ पहले से ही विद्यमान रहे हैं ORM पुस्तकालयों कि यह कार्यक्षमता के कुछ प्रदान करते हैं, लेकिन अब उन छूट कृपया पता है (वहाँ संभावना है कि एक डेटा भंडारण परत इन ORM पुस्तकालयों में से एक के साथ लागू किया जाता है) - यह भी ध्यान रखें मैं जानबूझकर आपको यह नहीं बता रहा हूं कि यहां कौन सी भाषा का उपयोग किया जा रहा है, इसके अलावा यह दृढ़ता से टाइप किया गया है।

मैं यहां कुछ सामान्य सलाह ढूंढ रहा हूं कि किस विधि का उपयोग करना बेहतर है (या कुछ और सुझाव देने के लिए स्वतंत्र महसूस करें), और क्यों।

Answer 1

मैं एक और विकल्प का सुझाव दे सकता है, संभवतः बेहतर decoupling साथ: व्यापार उपयोग डेटा वस्तुओं वस्तुओं, और डेटा वस्तुओं भंडारण वस्तुओं को लागू। स्टोरेज स्रोत या प्रारूप पर किसी भी निर्भरता के बिना, इसे डेटा ऑब्जेक्ट्स को किसी भी निर्भरता के समर्थन के लिए अनुमति देना चाहिए, जबकि स्टोरेज ऑब्जेक्ट्स को गतिशील रूप से बदलना (उदाहरण के लिए ऑनलाइन/ऑफलाइन मैनिपुलेशन)

यह उपरोक्त दूसरी श्रेणी में आता है (व्यावसायिक वस्तुएं डाटा स्टोरेज ऑब्जेक्ट्स को एन्सेप्लेट करती हैं), लेकिन स्टोरेज मैकेनिज्म से डाटा सेमेन्टिक्स को अधिक स्पष्ट रूप से

Answer 2

क्लाइंट को स्टोरेज ऑब्जेक्ट्स से सीधे निपटना नहीं चाहिए। वे डीटीओ के सीधे सौदे कर सकते हैं, लेकिन किसी भी ऑब्जेक्ट जिसमें आपके व्यापार ऑब्जेक्ट में लिपटे स्टोरेज के लिए कोई तर्क नहीं है, उसे क्लाइंट द्वारा सीधे नहीं कहा जाना चाहिए।

Answer 3

आप अपने क्लाइंट से सीधे व्यापार को कॉल करने के लिए एक मुखौटा भी रख सकते हैं। इसके अलावा यह आपके व्यापार के लिए सामान्य प्रवेश बिंदु बनाता है।

जैसा कि कहा गया है, आपके व्यापार को आपके डीटीओ और फेकाडे के अलावा कुछ भी नहीं बताया जाना चाहिए।

हां। आपका ग्राहक डीटीओ से निपट सकता है। यह आपके आवेदन के माध्यम से डेटा पास करने का आदर्श तरीका है।

Answer 4

रॉकी लोहतका द्वारा CSLA.net देखें।

Answer 5

सीएलएसए काफी समय से रहा है। हालांकि मुझे एरिक इवांस पुस्तक http://dddcommunity.org/

Answer 6

पर चर्चा के दृष्टिकोण को पसंद है, ठीक है, मैं यहां सह-कार्यकर्ता ग्रेग का उल्लेख करता हूं।

ग्रेग ने उन विकल्पों का वर्णन किया जो हम महान सटीकता के साथ विचार कर रहे हैं। मैं सिर्फ स्थिति विवरण में कुछ अतिरिक्त विचार जोड़ना चाहता हूं।

क्लाइंट कोड डेटास्टोरेज के बारे में अनजान हो सकता है जहां व्यावसायिक वस्तुओं को संग्रहीत किया जाता है, लेकिन यह संभव है कि केवल एक डेटास्टोरेज होने पर, या एक ही व्यापार ऑब्जेक्ट प्रकार के लिए कई डेटास्टोरेज हों (स्थानीय डेटाबेस में संग्रहीत उपयोगकर्ता और इन में बाहरी एलडीएपी) लेकिन ग्राहक इन व्यावसायिक वस्तुओं को नहीं बनाता है। सिस्टम विश्लेषण के संदर्भ में, इसका मतलब है कि वहां कोई उपयोग नहीं किया जाना चाहिए जिसमें एक ही प्रकार की वस्तुओं के दो डेटास्टोरेज का अस्तित्व उपयोग केस प्रवाह को प्रभावित कर सकता है।

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

यह ज़िम्मेदारी कई तरीकों से लागू की जा सकती है: यह प्रत्येक डेटा भंडारण के लिए विशिष्ट प्रकार का कनेक्शन ऑब्जेक्ट हो सकता है; यह नए बो उदाहरणों आदि

सादर बनाने के लिए कॉल करने के लिए किया जा सकता है segregared तरीकों

माइकल

Answer 7

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

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

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

छद्म कोड में:

using(MyConcreteBusinessContext ctx = new MyConcreteBusinessContext("datares://model1?DataSource=myserver;Catalog=mydatabase;Trusted_Connection=True ruleres://someruleresource?type=StaticRules&handler=My.Org.Business.Model.RuleManager")) { 

User user = ctx.GetUserById("SZE543"); 
user.IsLogonActive = false; 
ctx.Save(); 
} 

//a business object 
class User : BusinessBase { 
    public User(BusinessContext ctx) : base(ctx) {} 

    public bool Validate() { 
    IValidator v = ctx.GetValidator(this); 
    return v.Validate(); 
    } 
} 

// a validator 
class UserValidator : BaseValidator, IValidator { 
User userInstance; 
public UserValidator(User user) { 
    userInstance = user; 
} 

public bool Validate() { 
    // actual validation code here 
    return true; 
} 
}