फैक्टरी पैटर्न के साथ डेटा सहेजा जा रहा है?

Question

मैं फैक्टरी पैटर्न (रणनीति पैटर्न के साथ) से अधिक परिचित हो रहा हूं और पैटर्न के पास कितना बड़ा लाभ हो सकता है। हालांकि, मैं निम्नलिखित परिस्थितियों से जूझ रहा हूं:

पहले, मैंने निम्नलिखित की तरह कुछ किया होगा, जहां एक प्रबंधक वर्ग है जो कार का निर्माण और बचत करेगा। यहां कोई निर्भरता इंजेक्शन नहीं है और यह एक खराब कार्यान्वयन है, खासकर जब यूनिट परीक्षण की कोशिश कर रहा है।

public class CarManager 
{ 
    public static Car GetCarFromDatabase(int carId) { return new Car(); } 

    public static void SaveCar(Car car) { } 
} 

मैं अब देखते हैं कि कैसे मैं अलग Factories कि मेरे लिए कारों का निर्माण, चाहे वह एक डेटाबेस, या जहां से होना हो सकता था! यह भी खूब रही! तो, यहां मेरे प्रश्न हैं:

प्रश्न 1: यह मेरी समझ है कि Factories केवल ऑब्जेक्ट्स बनाना चाहिए, क्या यह सही है? यदि हां, तो मेरे दूसरे प्रश्न के बारे में क्या?

प्रश्न 2: यदि मैं अपनी वस्तुओं के निर्माण के लिए फैक्टरी पैटर्न का पालन कर रहा हूं, तो मुझे अपनी वस्तुओं को बचाने के बारे में कैसे जाना चाहिए? क्या इसके लिए कोई अलग पैटर्न है, या क्या मैं फैक्टरी पैटर्न को पूरी तरह समझ नहीं रहा हूं?

Answer 1

Factory पैटर्न वस्तुओं के निर्माण में मदद करने के लिए माना जाता है। यही कारण है कि इसे "निर्माण" पैटर्न के रूप में वर्गीकृत किया गया है। अपने पहले प्रश्न का उत्तर देने के लिए, वस्तुओं का पालन करने के लिए इसका उपयोग नहीं किया जाना चाहिए।

Repository pattern एक दृढ़ता पैटर्न है जिसका उपयोग वस्तुओं को कुछ दृढ़ता तंत्र में सहेजने या दृढ़ता तंत्र से डेटा पुनर्प्राप्त करने के लिए किया जाना चाहिए। यह वास्तव में है, मार्टिन फाउलर के अनुसार, एक उद्यम पैटर्न जिसे सामान्य डिजाइन पैटर्न से अलग किया जाना चाहिए।

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

Answer 2

फैक्टरी डेटा को सहेजना नहीं चाहिए। डेटा एक्सेस ऑब्जेक्ट (डीएओ) या टेबल मैपर एक बेहतर विचार होगा।

Answer 3

सामान्यतः, मुझे लगता है कि आप गलत कोण से इस पर पहुंच रहे हैं।

आपको उस समस्या की पहचान करने की आवश्यकता है जिसे आप हल करने का प्रयास कर रहे हैं, और फिर उस समस्या के अनुरूप समाधान ढूंढें। यह मुझे लगता है जैसे आपने एक निश्चित पैटर्न खोजा है, और फिर आप जिस समस्या का सामना करते हैं उसे लागू करने की कोशिश कर रहे हैं।

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

Answer 4

क्यू 1 - हां, फैक्टरी पैटर्न आदर्श रूप से वस्तुओं के निर्माण के लिए उपयोग किया जाना चाहिए। तो, आप कारखाने पैटर्न का उपयोग कर अपनी कार वस्तु बना सकते हैं।

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

Answer 5

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

namespace Domain.App 
{ 
    public class PresentationClass 
    { 
     private Collection<ISomeOutput> GetData(ISomeInput1 input) 
     { 
      ServicesLogicContext logic = new ServicesLogicContext((MyType) Identifier); 
      return logic.GetSomeData(input) as Collection<ISomeOutput>; 
     } 
     private IMethodResult ExecuteSomeAction(ISomeInput2 input) 
     { 
      ServicesLogicContext logic = new ServicesLogicContext((MyType) Identifier); 
      return logic.ExecuteSomeAction(input); 
     } 
    } 
} 

namespace Domain.Logic 
{ 
    public sealed class ServicesLogicContext : ServicesLogicContextBase 
    { 
     public IList<ISomeOutput> GetSomeData(ISomeInput1 input) 
     { 
      DBServices services = DBServicesProvider.CreateServices(SomeIdentifier); 
      return DBServicesProvider.GetSomeData(input); 
     } 
     public IMethodResult ExecuteSomeAction(ISomeInput2 input) 
     { 
      DBServices services = DBServicesProvider.CreateServices(SomeIdentifier); 
      IMethodResult result = services.ExecuteSomeAction(input); 
      return result; 
     } 
    } 
} 

namespace Domain.Data 
{ 
    public abstract class DBServices : IServices 
    { 
     public virtual IList<ISomeOutput> GetSomeData(ISomeInput1 input) {...} 
     public virtual IMethodResult ExecuteSomeAction(ISomeInput2 input) {...} 
    } 

    public class DBServicesSpecific1 : DBServices 
    { 
     public override IList<ISomeOutput> GetSomeData(ISomeInput1 input) {...} 
     public override IMethodResult ExecuteSomeAction(ISomeInput2 input) {...} 
    } 

    public class DBServicesSpecific2 : DBServices 
    { 
     public override IList<ISomeOutput> GetSomeData(ISomeInput1 input) {...} 
     public override IMethodResult ExecuteSomeAction(ISomeInput2 input) {...} 
    } 

    public sealed class DBServicesProvider 
    { 
     public static DBServices CreateServices(MyType identifier) 
     { 
      DBServices result = null;  
      switch(identifier) 
      { 
       case MyType.Specific1: result = new DBServicesSpecific1(); break; 
       case MyType.Specific2: result = new DBServicesSpecific2(); break;  
      } 
      return result; 
     } 
    } 
}