ओआरएम और परतें

Question

इस बिंदु के लिए यहां सभी जगहों पर खेद है ... लेकिन मुझे लगता है कि कुत्ते की तरह मेरी पूंछ का पीछा करते हुए और मैं इस बिंदु पर उलझन में हूं।

मैं 3 टायर समाधान (आईएल, बीएल, डीएल) विकसित करने का सबसे साफ तरीका देखने की कोशिश कर रहा हूं जहां डीएल एक डीबी के लिए उपयोग करने के लिए ओआरएम का उपयोग कर रहा है।

हर जगह मैंने देखा है, लोग डीबी टेबल्स का प्रतिनिधित्व करने वाली वस्तुओं को उत्पन्न करने के लिए या तो LinqToSQL या LLBLGen Pro का उपयोग करते हैं, और उन सभी वर्गों को उन सभी 3 परतों में संदर्भित करते हैं। लगता है कि 40 साल के कोडिंग पैटर्न को नजरअंदाज कर दिया गया है - या एक प्रतिमान शिफ्ट हुआ है, और मुझे स्पष्टीकरण भाग याद आया कि ऐसा करने के लिए बिल्कुल ठीक क्यों है।

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

तो, पूर्ण मूल बातें करने के लिए वापस जा रहा है, यहाँ बुनियादी भागों मैं एक बहुत ही बहुत साफ तरीके से एकत्र कर लें करना चाहते हैं कि इस प्रकार हैं:

विधानसभाओं मैं से शुरू कर रहा हूँ: UL.dll BL.dll DL.dll

मुख्य वर्गों:

एक संदेश वर्ग MessageAddress वस्तुओं की एक संपत्ति उजागर संग्रह (बुलाया MessageAddresses) है:

class Message 
{ 
    public MessageAddress From {get;} 
    public MessageAddresses To {get;} 
} 

कार्यों परत प्रति:

बीएल यूआई GetMessage (GUID आईडी) जो संदेश का एक उदाहरण देता है कहा जाता है के लिए एक विधि को उजागर करता है।

बीएल बदले में डीएल को लपेटता है।

डीएल में एक प्रदाता फैक्ट्री है जो प्रदाता उदाहरण को लपेटती है। DL.ProviderFactory खुलासा करता है (संभवतः ... मेरे प्रश्नों का हिस्सा) GetMessage (Guid id) नामक दो स्थैतिक विधियों, और SaveMessage (संदेश संदेश) अंतिम लक्ष्य एक प्रदाता को स्वैप करने में सक्षम होना होगा LLBLGen Pro के लिए Linq2SQL के लिए लिखा गया है, या कोई अन्य प्रदाता जो ओआरएम (जैसे VistaDB) के खिलाफ काम नहीं कर रहा है।

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

इसलिए, इस का क्या मतलब है कि:

क) संदेश बीएल ख) DB/Orm/डीबी तालिका के मैनुअल प्रतिनिधित्व में परिभाषित किया गया है ('DbMessageRecord', या 'MessageEntity', या जो कुछ भी बाकी ORM इसे कॉल करता है) डीएल में परिभाषित किया गया है। सी) बीएल पर डीएल डी पर निर्भरता है डी) डीएल विधियों को कॉल करने से पहले, जिन्हें बीएल के बारे में रेफरी या पता नहीं है, बीएल को उन्हें बीएल इकाइयों को परिवर्तित करना है (उदाहरण: डीबीमेसेज रिकार्ड)?

यूएल:

Main() 
{ 
    id = 1; 
    Message m = BL.GetMessage(id); 
    Console.Write (string.Format("{0} to {1} recipients...", m.From, m.To.Count)); 
} 

बीएल:

static class MessageService 
{ 
    public static Message GetMessage(id) 
    { 
     DbMessageRecord message = DLManager.GetMessage(id); 
     DbMessageAddressRecord[] messageAddresses = DLManager.GetMessageAddresses(id); 

     return MapMessage(message, 
    } 

    protected static Message MapMessage(DbMessageRecord dbMessage. DbMessageAddressRecord[] dbAddresses) 
    { 
     Message m = new Message(dbMessage.From); 
     foreach(DbMessageAddressRecord dbAddressRecord in dbAddresses){ 
     m.To.Add(new MessageAddress (dbAddressRecord.Name, dbAddressRecord.Address); 
    } 
} 

डीएल:

static class MessageManager 
{ 
    public static DbMessageRecord GetMessage(id); 
    public static DbMessageAddressRecord GetMessageAddresses(id); 
} 

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

इच्छा है कि मैं प्रश्न पूछ सकूं ... लेकिन मैं वास्तव में इस बिंदु पर खो गया हूं। किसी भी तरह की सहायता का स्वागत किया जाएगा।

Answer 1

जो कि जगह पर थोड़ा सा है और मुझे अपने पहले प्रयासों को ओआरएम और डीडीडी में याद दिलाता है। मैं व्यक्तिगत रूप से कोर डोमेन ऑब्जेक्ट्स, मैसेजिंग ऑब्जेक्ट्स, संदेश हैंडलर और रिपॉजिटरीज़ का उपयोग करता हूं। तो मेरा यूआई एक हैंडलर को एक संदेश भेजता है जो बदले में मेरी वस्तुओं को भंडारों के माध्यम से हाइड्रेट करता है और उस डोमेन ऑब्जेक्ट में व्यावसायिक तर्क निष्पादित करता है। मैं अपने डेटा एक्सेस और FluentNHibernate के लिए NHosernate का उपयोग loosy goosey .hbm कॉन्फ़िगरेशन के बजाय टाइप बाध्यकारी के लिए करता हूं।

तो संदेश मेरे यूआई और मेरे हैंडलर के बीच साझा किया गया है और सभी बीएल डोमेन पर हैं।

मुझे पता है कि मैंने अपने स्पष्टीकरण के लिए सजा के लिए खुद को खोला होगा, अगर यह स्पष्ट नहीं है कि मैं बाद में बचाव करूंगा।

व्यक्तिगत रूप से मैं कोड उत्पन्न वस्तुओं का बड़ा प्रशंसक नहीं हूं।

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

[Serializable] 
public class AddMediaCategoryRequest : IRequest<AddMediaCategoryResponse> 
{ 
    private readonly Guid _parentCategory; 
    private readonly string _label; 
    private readonly string _description; 

    public AddMediaCategoryRequest(Guid parentCategory, string label, string description) 
    { 
     _parentCategory = parentCategory; 
     _description = description; 
     _label = label; 
    } 

    public string Description 
    { 
     get { return _description; } 
    } 

    public string Label 
    { 
     get { return _label; } 
    } 

    public Guid ParentCategory 
    { 
     get { return _parentCategory; } 
    } 
} 

[Serializable] 
public class AddMediaCategoryResponse : Response 
{ 
    public Guid ID; 
} 


public interface IRequest<T> : IRequest where T : Response, new() {} 


[Serializable] 
public class Response 
{ 
    protected bool _success; 
    private string _failureMessage = "This is the default error message. If a failure has been reported, it should have overwritten this message."; 
    private Exception _exception; 

    public Response() 
    { 
     _success = false; 
    } 

    public Response(bool success) 
    { 
     _success = success; 
    } 

    public Response(string failureMessage) 
    { 
     _failureMessage = failureMessage; 
    } 

    public Response(string failureMessage, Exception exception) 
    { 
     _failureMessage = failureMessage; 
     _exception = exception; 
    } 

    public bool Success 
    { 
     get { return _success; } 
    } 

    public string FailureMessage 
    { 
     get { return _failureMessage; } 
    } 

    public Exception Exception 
    { 
     get { return _exception; } 
    } 

    public void Failed(string failureMessage) 
    { 
     _success = false; 
     _failureMessage = failureMessage; 
    } 

    public void Failed(string failureMessage, Exception exception) 
    { 
     _success = false; 
     _failureMessage = failureMessage; 
     _exception = exception; 
    } 
} 


public class AddMediaCategoryRequestHandler : IRequestHandler<AddMediaCategoryRequest,AddMediaCategoryResponse> 
{ 
    private readonly IMediaCategoryRepository _mediaCategoryRepository; 
    public AddMediaCategoryRequestHandler(IMediaCategoryRepository mediaCategoryRepository) 
    { 
     _mediaCategoryRepository = mediaCategoryRepository; 
    } 

    public AddMediaCategoryResponse HandleRequest(AddMediaCategoryRequest request) 
    { 
     MediaCategory parentCategory = null; 
     MediaCategory mediaCategory = new MediaCategory(request.Description, request.Label,false); 
     Guid id = _mediaCategoryRepository.Save(mediaCategory); 
     if(request.ParentCategory!=Guid.Empty) 
     { 
      parentCategory = _mediaCategoryRepository.Get(request.ParentCategory); 
      parentCategory.AddCategoryTo(mediaCategory); 
     } 
     AddMediaCategoryResponse response = new AddMediaCategoryResponse(); 
     response.ID = id; 
     return response; 
    } 
} 

मैं इस पर और पर चला जाता है पता है, लेकिन यह बुनियादी प्रणाली में सेवा की है मुझे बहुत अच्छी तरह से खत्म हो गया जो पिछले साल या तो

आप देख सकते हैं कि तुलना में हैंडलर डोमेन वस्तु डोमेन विशिष्ट तर्क

Answer 2

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

स्पष्ट रूप से मुझे आपके कोड बेस का पूरा दायरा नहीं पता है इसलिए दर्द और लाभ पर विचार करें।

Answer 3

यह शायद एक अप्रत्यक्ष उत्तर है, लेकिन पिछले साल मैंने जावा दुनिया में इस तरह के प्रश्नों के साथ कुश्ती की और Martin Fowler's Patterns of Enterprise Application Architecture काफी उपयोगी पाया (उसके pattern catalog भी देखें)। कई पैटर्न एक ही मुद्दे से निपटते हैं जिसके साथ आप संघर्ष कर रहे हैं।वे सभी अच्छी तरह से अमूर्त हैं और मुझे उच्च स्तर पर समस्या को देखने में सक्षम होने के लिए मेरी सोच को व्यवस्थित करने में मदद मिली।

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

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

संपादित करें: @ सीएल, आप काफी सही हैं, एक डीटीओ इंस्टेंस सिर्फ एक पॉको है (या मेरे मामले में जावा POJO)। एक व्यक्ति डीटीओ में "जिम" का पहला_नाम क्षेत्र हो सकता है और इसी तरह। प्रत्येक डीटीओ मूल रूप से डेटाबेस तालिका की एक पंक्ति से मेल खाता है और केवल खेतों का एक बंडल है, और कुछ भी नहीं। इसका मतलब यह है कि यह डीएल के साथ मिलकर नहीं है और यूआई तक पहुंचने के लिए पूरी तरह उपयुक्त है। फाउलर पी पर इनके बारे में बात करते हैं। 401 (अपने दांतों को काटने के लिए एक बुरा पहला पैटर्न नहीं)।

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

यदि आपके डेटा मॉडल ऑब्जेक्ट्स में ओआरएम-विशिष्ट एड-ऑन के सभी प्रकार हैं, तो मैं देख सकता हूं कि यूआई परत तक उन्हें उजागर करने से पहले आप दो बार क्यों सोचेंगे। लेकिन वहाँ आप एक सी # इंटरफ़ेस है कि केवल परिभाषित करता है POCO हो और तरीकों निर्धारित करते हैं, और का उपयोग करें कि आपके सभी गैर डीएल APIs में बना सकते हैं, और एक कार्यान्वयन वर्ग यह सभी ORM-विशिष्ट सामान है कि बनाने के लिए:

interface Person ... 

class ORMPerson : Person ... 

तो अगर आप अपने ORM बाद में बदलते हैं, तो वैकल्पिक POCO क्रियान्वयन कर सकें:

class NewORMPerson : Person ... 

और है कि केवल अपने डीएल परत कोड, क्योंकि आपके बीएल और यूआई कोड व्यक्ति का उपयोग करता है पर असर पड़ेगा।

@Zvolkov (नीचे) अगले स्तर तक "इंटरफेस को कोडिंग, कार्यान्वयन नहीं" के इस दृष्टिकोण को लेकर सुझाव देता है कि आप अपना आवेदन इस तरह से लिख सकते हैं कि आपका सभी कोड व्यक्ति वस्तुओं का उपयोग करता है, और आप dependency injection फ्रेमवर्क का उपयोग कर सकते हैं ताकि आप उस ओआरएम का उपयोग कर सकें जो ओआरएम आप उस दिन

Answer 4

मेरी राय केवल, वाईएमएमवी के उपयोग के आधार पर ORMPersons या NewORMPersons बनाने के लिए अपने अनुप्रयोग को गतिशील रूप से कॉन्फ़िगर करने के लिए कर सकते हैं।

जब मैं किसी भी नई तकनीक से गड़बड़ कर रहा हूं, मुझे लगता है कि इसे दो मानदंडों को पूरा करना चाहिए या मैं अपना समय बर्बाद कर रहा हूं। (या मैं इसे काफी अच्छी तरह से समझ में नहीं आता।)

1. इसे चीजों को सरल बनाना चाहिए, या सबसे खराब मामला उन्हें और जटिल नहीं बना सकता है।

2. यह युग्मन बढ़ाने या संयोजकता को कम नहीं करना चाहिए।

ऐसा लगता है कि आपको लगता है जैसे आप विपरीत दिशा है, जो मैं जानता हूँ कि या तो LINQ या ORMs के लिए इरादा नहीं है में जा रहे हैं लगता है।

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

Answer 5

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

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

Llblgen के बारे में निश्चित नहीं है, लेकिन NHibernate + किसी भी IoC जैसे SpringFramework.NET या विंडसर इस तरह का समर्थन करने वाला सुंदर साफ मॉडल प्रदान करता है।