अगर मैं सही तरीके से प्रश्न समझता हूं, तो आपने एक डोमेन मॉडल
बनाया है और आप अपने डेटाबेस और अपने डोमेन ऑब्जेक्ट्स के रिकॉर्ड के
बीच मैप करने के लिए ऑब्जेक्ट-रिलेशनल मैपर लिखना चाहते हैं। हालांकि,
आप अपने डोमेन मॉडल को 'प्लंबिंग' कोड के साथ प्रदूषित करने के बारे
में चिंतित हैं जो आपके ऑब्जेक्ट के फ़ील्ड को पढ़ने और लिखना आवश्यक
होगा।
एक कदम पीछे लेना, आपके पास अनिवार्य रूप से दो डेटा हैं जहां अपना
डेटा मैपिंग कोड डालना है - डोमेन क्लास के भीतर या बाहरी मैपिंग
क्लास में। पहला विकल्प अक्सर सक्रिय रिकॉर्ड पैटर्न कहा जाता है और
इसका लाभ यह है कि प्रत्येक ऑब्जेक्ट जानता है कि कैसे खुद को बनाए
रखना है और इसकी आंतरिक संरचना में पर्याप्त पहुंच है ताकि इसे
गैर-व्यावसायिक संबंधित क्षेत्रों का पर्दाफाश किए बिना मैपिंग करने
की अनुमति मिल सके।
उदा
public class User
{
private string name;
private AccountStatus status;
private User()
{
}
public string Name
{
get { return name; }
set { name = value; }
}
public AccountStatus Status
{
get { return status; }
}
public void Activate()
{
status = AccountStatus.Active;
}
public void Suspend()
{
status = AccountStatus.Suspended;
}
public static User GetById(int id)
{
User fetchedUser = new User();
//Lots of database and error-checking code
//omitted for clarity
//...
fetchedUser.name = (string) reader["Name"];
fetchedUser.status = (int)reader["statusCode"] == 0 ? AccountStatus.Suspended : AccountStatus.Active;
return fetchedUser;
}
public static void Save(User user)
{
//Code to save User's internal structure to database
//...
}
}
इस उदाहरण में, हमारे पास एक ऑब्जेक्ट है जो किसी उपयोगकर्ता को
नाम और खातास्टैटस के साथ प्रस्तुत करता है। हम स्थिति को सीधे सेट
करने की अनुमति नहीं देना चाहते हैं, शायद इसलिए कि हम यह जांचना
चाहते हैं कि परिवर्तन वैध स्थिति संक्रमण है, इसलिए हमारे पास एक
सेटटर नहीं है। सौभाग्य से, GetById में मैपिंग कोड और स्थैतिक
विधियों को सहेजें ऑब्जेक्ट के नाम और स्थिति फ़ील्ड तक पूर्ण पहुंच
है।
The second option is to have a second class that is responsible
for the mapping. This has the advantage of seperating out the
different concerns of business logic and persistence which can
allow your design to be more testable and flexible. The challenge
with this method is how to expose the name and status fields to the
external class. Some options are: 1. Use reflection (which has no
qualms about digging deep into your object's private parts) 2.
Provide specially-named, public setters (उदा. prefix them with the
word 'Private') and hope no one uses them accidentally 3. If your
language suports it, make the setters internal but grant your data
mapper module access. उदा. use the InternalsVisibleToAttribute in
.NET 2.0 onwards or friend functions in C++
अधिक जानकारी के लिए, मैं मार्टिन फाउलर की क्लासिक पुस्तक
'एंटरटेनमेंट आर्किटेक्चर के पैटर्न' की सिफारिश करता हूं
हालांकि, चेतावनी के एक शब्द के रूप में, अपने स्वयं के मैपर्स
लिखने के मार्ग से नीचे जाने से पहले मैं दृढ़ता से एक तृतीय-पक्ष
ऑब्जेक्ट रिलेशनल मैपर (ओआरएम) टूल जैसे एनएचबर्ननेट या माइक्रोसॉफ्ट
के एंटिटी फ्रेमवर्क का उपयोग करने की सलाह देता हूं। मैंने चार
अलग-अलग परियोजनाओं पर काम किया है, जहां कई कारणों से, हमने अपना खुद
का मैपर लिखा है और कोड लिखने के बजाय मैपर को बनाए रखने और विस्तार
करने में बहुत समय बर्बाद करना बहुत आसान है जो अंतिम उपयोगकर्ता
मूल्य प्रदान करता है। मैंने अभी तक एक परियोजना पर nHibernate का
उपयोग किया है और, हालांकि शुरुआत में काफी सीधी सीखने की वक्र है,
लेकिन आपके द्वारा शुरू किए गए निवेश में काफी भुगतान किया जाता
है।