2011-04-15 17 views
6

आज्ञा देना वहां कुछ अलग डीएओ कक्षाएं OrderDAO, ProductDAO, और CustomerDAO कि स्टोर/डेटाबेस में डेटा पुनः प्राप्त और एक उदाहरण DataSource (डेटाबेस कनेक्शन कारखाना) को साझा करें।प्रश्न

DataSource उदाहरण बनाने के लिए और इसे DAOs में प्लग करें हम आमतौर पर स्प्रिंग डी का उपयोग करते हैं। अब मैं बिना किसी डी फ्रेमवर्क के स्कैला में ऐसा करना चाहता हूं।

मैं cake pattern के बारे में पढ़ा है, और जैसे मैं निम्न करना चाहिए यह लग रहा है:

trait DatabaseContext { val dataSource:Datasource } 

trait OrderDAO {this:DatabaseContext => 
    ... // use dataSource of DatabaseContext 
} 

trait ProductDAO {this:DatabaseContext => 
    ... // use dataSource of DatabaseContext 
} 

object DAOImpl extends OrderDAO with ProductDAO with DatabaseContext { 
    val dataSource = ... // init the data source 
} 

मैं सही ढंग से केक पैटर्न समझ रहे हो?

क्या मैं केक पैटर्न का उपयोग करके इन DAOs को अलग-अलग कार्यान्वित कर सकता हूं?

यह क्या प्रदान करता है कि डीआई ढांचे जैसे वसंत नहीं करते हैं?

मैं अलग OrderDAOImpl और ProductDAOImpl ऑब्जेक्ट्स को एक बड़े DAOImpl के बजाय DataSource उदाहरण साझा करने के तरीके कैसे बना सकता हूं?

+0

मैंने संक्षिप्त रूप से केक पैटर्न के बारे में पढ़ा और यह नहीं देखा कि उत्साह या तो क्या था। यह मौजूदा डी कंटेनरों की तुलना में बहुत अधिक जटिल लगता है। – Kevin

+0

चाहे आप इसे पसंद करते हैं या नहीं, वास्तव में प्रश्न के लिए प्रासंगिक नहीं हैं। और "क्या मुझे कुछ याद आ रहा है" एक बहुत ही कमजोर सवाल है। शायद यह पूछना बेहतर होगा कि "यह क्या प्रदान करता है कि एक्स नहीं करता है?", जो एक स्पष्ट सवाल है। –

+0

@ डैनियल। धन्यवाद। मैंने सवाल दोहराया है। – Michael

उत्तर

2

शायद:

  • स्थिरता संकलन समय पर जाँच की।
5

केक पैटर्न के लाभ हैं:

  • विन्यास-फ़ाइल-आधारित डि समाधान के विपरीत, ठेके मिलान के कार्यान्वयन संकलन समय है, जो वर्ग खोजने और संगतता समस्याओं को कम कर देता पर किया जाता है। हालांकि, कई डी इंजनों में वैकल्पिक इन-कोड कॉन्फ़िगरेशन सुविधा
  • कोई तृतीय-पक्ष लाइब्रेरी उपयोग नहीं किया जाता है। स्व-प्रकार एनोटेशन जो आपको पैटर्न का उपयोग करने देते हैं मूल भाषा सुविधा हैं। कोई विशेष वाक्य रचना अनुबंध
  • एक घटक में एक और घटक परिणाम के लिए आवश्यक एक रनटाइम त्रुटि के लिए एक कार्यान्वयन निर्दिष्ट करने के लिए भूलकर की कार्यान्वयन पुनः प्राप्त करने के लिए किया जाता है - बस इस लेख http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html की जाँच करें और में से एक को निर्दिष्ट नहीं की कोशिश घटकों या केक पैटर्न के किसी भी उदाहरण में एक ठोस वर्ग के बजाय एक विशेषता निर्दिष्ट करने या यहां तक ​​कि एक वैल

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

आपके उदाहरण कड़ाई से केक पैटर्न प्रतीत नहीं होते हैं। आपके मामले में आप अपने गुणों के लिए कार्यान्वयन बनाने के लिए विरासत का उपयोग कर सकते थे और प्रत्येक डीएओ घटक के लिए अलग-अलग कक्षाओं का उपयोग कर सकते थे। केक पैटर्न में उपभोग करने वाला कोड डीएओ कोड की तरह एक घटक होगा, और निर्भरता को इकट्ठा करने वाला कोड एक साथ खड़ा होगा।

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

यह कम

trait OrderDAOComponent { 
    val dao: OrderDAO 
    trait OrderDAO { 
     def create: Order 
     def delete(id: Int): Unit 
     //etc 
    } 
} 

trait OrderDAOComponentImpl extends OrderDAOComponent { 
    class OrderDAOJDBCImpl extends OrderDAO { 
     def create: Order = {/*JDBC-related code here*/} 
     def delete(id: Int) {/*JDBC-related code here*/} 
     //etc 
    } 
} 

//This one has a dependency 
trait OrderWebUIComponentImpl { 
    this: OrderDAOComponent => 
    class OrderWebUI { 
     def ajaxDelete(request:HttpRequest) = { 
      val id = request.params("id").toInt 
      try { 
       dao.delete(id) 
       200 
      } 
      catch { 
       case _ => 500 
      } 

     } 
    } 
} 

//This matches contracts to implementations 

object ComponentRegistry extends 
    OrderDAOComponentImpl with 
    OrderWebUIComponentImpl 
{ 
    val dao = new OrderDAOJDBCImpl 
    val ui = new OrderWebUI 
} 

//from some front-end code 
val status = ComponentRegistry.ui.ajaxDelete(request) 

अपने उदाहरण पर अधिक बनाने के लिए,। मुझे लगता है कि यह केक की तरह अधिक हो सकता है यदि:

trait DatabaseContext { val dataSource:Datasource } 

trait OrderDAOComponent {this:DatabaseContext => 
    trait OrderDAOImpl { 
     ... // use dataSource of DatabaseContext 
    } 
} 

trait ProductDAOComponent {this:DatabaseContext => 
    trait ProductDAOImpl { 
     ... // use dataSource of DatabaseContext 
    } 
} 

object Registry extends OrderDAOComponent with ProductDAOComponent with DatabaseContextImpl { 
    val dataSource = new DatasourceImpl //if Datasource is a custom trait, otherwise wrapping needed 
    val orderDAO = new OrderDAOImpl 
    val productDAO = new ProductDAOImpl 
} 

//now you may use them separately 
Registry.orderDAO.// 
संबंधित मुद्दे