स्कैला स्लिम केक पैटर्न: 9 000 से अधिक कक्षाएं?

Question

मैं एक खेल विकसित कर रहा हूँ! स्लैक 2.0 के साथ स्कैला में 2.2 एप्लिकेशन और अब मैं केक पैटर्न का उपयोग करने की कोशिश कर रहा हूं, डेटा एक्सेस पहलू से निपट रहा हूं। यह आशाजनक प्रतीत होता है लेकिन मुझे वास्तव में ऐसा लगता है कि मुझे वास्तव में कुछ सरल प्राप्त करने के लिए कक्षाओं/गुणों/वस्तुओं का एक बड़ा समूह लिखना होगा। तो मैं इस पर कुछ प्रकाश का उपयोग कर सकता था।

एक User अवधारणा के साथ एक बहुत ही सरल उदाहरण लें तो जिस तरह से मैं समझता हूँ कि यह है कि हम होना चाहिए:

case class User(...) //model 

class Users extends Table[User]... //Slick Table 

object users extends TableQuery[Users] { //Slick Query 
//custom queries 
} 

अब तक यह पूरी तरह से उचित है। अब हम एक "केक Patternable" UserRepository जोड़ें:

trait UserRepository { 
val userRepo: UserRepository 
class UserRepositoryImpl { 
    //Here I can do some stuff with slick 
    def findByName(name: String) = { 
     users.withFilter(_.name === name).list 
    } 
    } 
} 

फिर हम एक UserService:

trait UserService { 
this: UserRepository => 
val userService: UserService 
class UserServiceImpl { // 
    def findByName(name: String) = { 
     userRepo.findByName(name) 
    } 
    } 
} 

अब हम एक वस्तु में इस सब के मिश्रण:

object UserModule extends UserService with UserRepository { 
    val userRepo = new UserRepositoryImpl 
    val userService = new UserServiceImpl 
} 

1. UserRepository वास्तव में उपयोगी है? मैं Users स्लिम ऑब्जेक्ट में कस्टम क्वेरी के रूप में findByName लिख सकता था।

2. मान लें कि मेरे पास Customer के लिए इस तरह के वर्गों का एक और सेट है, और मुझे इसमें कुछ UserService सुविधाएं उपयोग करने की आवश्यकता है।

मुझे क्या करना चाहिए:

CustomerService { 
this: UserService => 
... 
} 

या

CustomerService { 
val userService = UserModule.userService 
... 
} 

Answer 1

ठीक है, अच्छा लक्ष्यों की तरह उन ध्वनि:

डेटाबेस पुस्तकालय (चालाक अधिक

• सार, .. ।

  trait UserRepository { 
      type User 
      def findByName(name: String): User 
  } 
  
  // Implementation using Slick 
  trait SlickUserRepository extends UserRepository { 
      case class User() 
      def findByName(name: String) = { 
       // Slick code 
      } 
  } 
  
  // Implementation using Rough 
  trait RoughUserRepository extends UserRepository { 
      case class User() 
      def findByName(name: String) = { 
       // Rough code 
      } 
  } 
  

  फिर CustomerRepository के लिए

  तुम कर सकते हो:)

• लक्षण इकाई परीक्षण योग्य

आप कुछ इस तरह कर सकता है बनाओ

trait CustomerRepository { this: UserRepository => 
} 

trait SlickCustomerRepository extends CustomerRepository { 
} 

trait RoughCustomerRepository extends CustomerRepository { 
} 

और उन्हें अपने बैकएंड के आधार पर गठबंधन सनकी:

object UserModuleWithSlick 
    extends SlickUserRepository 
    with SlickCustomerRepository 

object UserModuleWithRough 
    extends RoughUserRepository 
    with RoughCustomerRepository 

,210

तुम इतनी तरह इकाई-परीक्षण योग्य वस्तुओं बना सकते हैं:

object CustomerRepositoryTest extends CustomerRepository with UserRepository { 
    type User = // some mock type 
    def findByName(name: String) = { 
     // some mock code 
    } 
} 

आप का पालन करने के

trait CustomerRepository { this: UserRepository => 
} 

object Module extends UserRepository with CustomerRepository 

और

trait CustomerRepository { 
    val userRepository: UserRepository 
    import userRepository._ 
} 

object UserModule extends UserRepository 
object CustomerModule extends CustomerRepository { 
    val userRepository: UserModule.type = UserModule 
} 

के बीच एक मजबूत समानता है कि वहाँ सही हैं यह वह जगह है पुरानी विरासत/एकत्रीकरण व्यापार, स्कैला दुनिया के लिए अद्यतन किया गया। प्रत्येक दृष्टिकोण के फायदे और नुकसान होते हैं। मिश्रण गुणों के साथ, आप कम कंक्रीट ऑब्जेक्ट्स बनाएंगे, जो ट्रैक रखने में आसान हो सकते हैं (जैसा ऊपर है, आपके पास केवल उपयोगकर्ताओं और ग्राहकों के लिए अलग-अलग ऑब्जेक्ट्स की बजाय Module ऑब्जेक्ट है)। दूसरी तरफ, ऑब्जेक्ट निर्माण समय पर लक्षणों को मिश्रित किया जाना चाहिए, इसलिए आप उदाहरण के लिए मौजूदा UserRepository नहीं ले सकते हैं और CustomerRepository इसे मिश्रण करके बना सकते हैं - यदि आपको ऐसा करने की आवश्यकता है, तो आपको एकत्रीकरण का उपयोग करना होगा। ध्यान दें कि स्केल को यह स्वीकार करने के लिए कि पथ-निर्भर प्रकार समान हैं, एकत्रीकरण के लिए अक्सर आपको सिंगलटन-प्रकार जैसे सिंगल (: UserModule.type) निर्दिष्ट करने की आवश्यकता होती है। लक्षणों को मिलाकर एक और शक्ति यह है कि यह रिकर्सिव निर्भरताओं को संभाल सकता है - UserModule और CustomerModule दोनों एक दूसरे से कुछ प्रदान करने और आवश्यकता के लिए कुछ प्रदान कर सकते हैं। यह आलसी vals का उपयोग करके एकत्रीकरण के साथ भी संभव है, लेकिन यह मिश्रण गुणों के साथ अधिक वाक्य रचनात्मक रूप से सुविधाजनक है।

Answer 2

मेरी हाल ही में प्रकाशित Slick architecture cheat sheet देखें। यह डेटाबेस चालक पर सार नहीं है, लेकिन यह मामूली है कि इसे इस तरह से बदल दें। बस

class Profile(profile: JdbcProfile){ 
    import profile.simple._ 
    lazy val db = ... 
    // <- cheat sheet code here 
} 

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

यदि डेटाबेस तालिका प्रति बार बार-बार सिंटैक्स ओवरहेड आपको परेशान करता है, तो कोड उत्पन्न करें। Slick code-generator is customizable बिल्कुल उस उद्देश्य के लिए:

यदि आप हाथ से लिखे गए और जेनरेट कोड को मिश्रित करना चाहते हैं, तो कोड-जनरेटर में हाथ से लिखित कोड फ़ीड करें या एक योजना का उपयोग करें, जहां जेनरेट कोड हाथ से लिखित कोर से प्राप्त होता है विपरीत क्रम में।

किसी और चीज से स्लिम को बदलने के लिए, किसी अन्य लाइब्रेरी का उपयोग करके क्वेरी के साथ डीएओ विधियों को प्रतिस्थापित करें।