2012-09-12 4 views
6

मैं user ऑब्जेक्ट का उदाहरण लेने जा रहा हूं। उपयोगकर्ता को पंजीकृत, लॉग इन, लॉग आउट, संपादित (उदाहरण के लिए, ईमेल परिवर्तन), आदिवेब एमवीसी: मॉडल परत को कैसे व्यवस्थित करें?

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

दूसरी ओर मेरे पास DAO कक्षा है जो ऑब्जेक्ट है जो विभिन्न प्रकार के MySQL/PDO क्वेरीज़ (रिकॉर्ड, अद्यतन, जानकारी पुनर्प्राप्त आदि) के माध्यम से सीधे डेटाबेस से संबंधित है।

क्या user ऑब्जेक्ट DAO ऑब्जेक्ट के साथ सीधे बातचीत करने का कोई कारण नहीं है? दूसरे शब्दों में, जब Controller किसी मौजूदा user उदाहरण (उदाहरण के लिए, पंजीकरण प्रक्रिया के दौरान) से संबंधित डेटाबेस क्वेरी का अनुरोध करता है, तो इसे user में केवल एक फ़ंक्शन कॉल करना चाहिए, जो स्वयं DAO में कोई फ़ंक्शन कॉल करता है, या बीच में एक परत होनी चाहिए ?

मैंने ऐसे उदाहरण देखे हैं जहां नियंत्रक डीएओ के साथ बातचीत करने के लिए तीसरी कक्षा को कॉल करता है, और user उदाहरण को एक तर्क के रूप में पास करता है। कभी-कभी इसके बजाय, यह तीसरी परत user उदाहरण बनाने और DAO से निपटने के साथ प्रभारी है। ऐसा लगता है कि DAO से निपटने के लिए उपयोग किए जाने वाले सभी कार्यों user ऑब्जेक्ट के अंदर रह सकते हैं। मैं क्या खो रहा हूँ?

उत्तर

2

मुझे लगता है कि आप मॉडलों के लिए कुछ प्रकार के एडाप्टर या गेटवे का वर्णन कर रहे हैं, जहां आपके पास एक कक्षा है जो एडाप्टर (यह डेटाबेस के साथ बातचीत कर सकती है, या एक एक्सएमएल डेटा स्रोत) कह सकती है और फिर परिणामों को उदाहरण देती है आपका मॉडल (यानी प्रत्येक मिलान करने वाला उपयोगकर्ता परिणाम आपके User मॉडल के उदाहरण के लिए असाइन करता है)।

अतीत में, मैंने आपके द्वारा वर्णित दृष्टिकोण लिया है जहां आपके पास एक मॉडल का प्रतिनिधित्व करने वाले मॉडल हैं, और फिर इन आइटमों को डेटा स्रोत में सहेजने और पुनर्प्राप्त करने के लिए एक डीएओ (यह डेटाबेस या जो भी हो), और नियंत्रक जो तर्क करता है। तो एक बहुत ही मूल संस्करण:

UsersDAO.php

class UsersDAO extends DAO 
{ 
    public function save(User $user) 
    { 
     return is_null($user->id) ? $this->insert($user) 
            : $this->update($user); 
    } 

    public function insert(User $user) 
    { 
     $sql = "INSERT INTO `users` (`username`, `password`) 
       VALUES (:username, :password)"; 

     $stmt = $this->db->prepare($sql); 
     $stmt->bindParam(':username', $user->username); 
     $stmt->bindParam(':password', $user->password); 
     $stmt->execute(); 
    } 
} 

User.php

class User 
{ 
    public $id; 
    public $username; 
    public $password; 
    public $email; 
} 

UsersController.php

class UserController extends Controller 
{ 
    public function register() 
    { 
     $usersDao = new UserDAO; 

     if ($_POST) { 
      $user = new User; 
      $user->username = $_POST['username']; 
      $user->password = $_POST['password']; 

      $userDao->save($user); 
     } 
    } 
} 

उम्मीद है कि यह मदद करता है।

+0

-1: उस कोड में से कोई भी नियंत्रक में नहीं है। प्रस्तुति परत में आपके पास डोमेन व्यवसाय तर्क है। और आप 'उपयोगकर्ता' "कक्षा" कोई encapsulation या व्यवहार प्रदान करता है। –

+0

ओह .. और 'userDAO' का आपका कोड उदाहरण वास्तव में डेटा मैपर है, [डीएओ नहीं] (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html)। डीएओ सीधे भंडारण के साथ बातचीत नहीं करते –

+0

@ tereško अपने समाधान को उत्तर के रूप में पोस्ट करने के लिए स्वतंत्र महसूस करें। साथ ही, यह सुनिश्चित न करें कि आप कैसे कह सकते हैं कि मेरे पास प्रस्तुति परत में डोमेन व्यवसाय तर्क है जब मैंने प्रस्तुति परत का एक उदाहरण भी पोस्ट नहीं किया है। –

3

आप MVC डिजाइन पैटर्न का पालन कर रहे हैं, तो कारण नहीं के लिए User उदाहरण नियंत्रक में हो रहा है। प्रस्तुति परत पर लीक करने के बजाय, यह मॉडल परत का हिस्सा होना चाहिए।

ऐसा लगता है कि आप क्या कहते हैं "नियंत्रक" वास्तव में एक सेवा है, जो मॉडल परत, कि डेटा भंडारण से संबंधित ढांचे (mappers, repositories, DAOs) पर domain objects के बीच बातचीत संभालती का एक हिस्सा होना चाहिए की अधिक है।

असल में, जो आप खो रहे हैं वह चिंताओं का सही अलगाव है।

नियंत्रक डोमेन व्यापार तर्क से निपटने के बजाय, पहचान या कुछ उपयोगकर्ता प्रबंधन सेवा को डेटा पास कर रहा है। कहा गया है कि सेवा को User ऑब्जेक्ट प्रारंभ करना चाहिए, डेटा को सत्यापित करें और इसे सहेजने का प्रयास करें। नियंत्रक को इनमें से किसी के बारे में पता नहीं होना चाहिए।

Something like this:

class SomeController 
{ 
    // ---- snip ---- 

    public function postRegister($request) 
    { 
      $accounts = $this->serviceFactory->create('AccountManagement'); 
      $account->create($request->getPost('username'), 
          $request->getPost('email'), 
          $request->getPost('password'), 
          $request->getPost('password2')); 

      $this->view->setState(View::STATE_POST); 
    } 

    // ---- snip ---- 
} 

class AccountManagement extends Service 
{ 
    // ---- snip ---- 

    public function addUser($username, $email, $password, $repeated_password) 
    { 

     $user = $this->domainObjectFactory->create('User'); 

     $user->setNickname($username); 
     $user->setEmail($email); 
     $user->setPassword($password); 
     $user->matchRepeatedPassword($repeated_password); 

     if ($user->isValid()) 
     { 
      $dao = $this->DAOFactory->create('User'); 
      $dao->save($user); 
     } 

     // additional code for saving the error state 
     // if domain object turns out to be invalid 
     // or DAO returns an error 
    } 

    // ---- snip ---- 
} 

पी.एस. आपको this post प्रासंगिक मिल सकता है।

+1

जो लोग डाउनवोट करते हैं, उन्हें तर्क की व्याख्या करनी चाहिए। –

+0

कक्षा स्थिरांक का उपयोग करने का क्या फायदा है? जैसे देखें :: STATE_POST? क्या आप नियंत्रक को छोड़कर अन्य स्थानों में इसका उपयोग करते हैं? क्यों न केवल $-> view-> setState ('post') का उपयोग करें; – Andrew

+0

कोई नहीं, यह पुराना पोस्ट है। यह तब था जब मैं अभी भी सभी ढांचे के बकवास से गुमराह था और सोचा था कि नियंत्रकों को विचारों को कुछ कहना है। –

संबंधित मुद्दे