2012-11-23 15 views
9

अपडेट करते समय दृश्य में एक जटिल ऑब्जेक्ट को कैसे बनाए रखें मुझे यह महसूस हो रहा है कि यह एक मूल प्रश्न हो सकता है!केवल एक छोटा सा हिस्सा

मेरे पास एक जटिल ऑब्जेक्ट यानी एक दस्तावेज़ ऑब्जेक्ट है जिसमें गुण हैं जो अन्य ऑब्जेक्ट्स की सूचियां हैं। यह कुछ एक्सएमएल deserializing द्वारा बनाया गया है।

मैं देखें

Return ViewResult(MyDoc) 

देखें कुछ गुण संपादित कर रहे हैं करने के लिए पूरे मॉडल पारित करने के लिए करना चाहते हैं। नियंत्रण फिर वापस पोस्ट नियंत्रक में लौट आता है:

 [AcceptVerbs(HttpVerbs.Post)] 
    public ActionResult Index(Document myDoc) 

"myDoc" अब बस अपना फार्म के क्षेत्रों का प्रतिनिधित्व करता है। मुझे संदेह है कि यह काम पर मॉडलबाइंडिंग है। तो मुझे लगता है कि मुझे अपनी जटिल वस्तु को एक छिपे हुए क्षेत्र में जारी रखना होगा (उदाहरण महान होगा) या सत्र ऑब्जेक्ट के रूप में। हालांकि मैं थोड़ा उलझन में हूं कि मेरा अद्यतन क्षेत्र लगातार ऑब्जेक्ट (छुपा या सत्र) में कैसे विलय हो जाता है।

उत्तर

3

आप सही हैं, यह मॉडल काम पर बाध्यकारी है।

बंधन लगभग स्वचालित रूप से जब आप इस तरह के रूप HtmlHelpers का उपयोग होता है:

@Html.TextboxFor(model => model.PropertyName) 

इस लाइन वास्तव में इस तरह एक छोटा सा कुछ बनाता है:

<input type="textbox" id="Modelobject_PropertyName" name="ModelObject.PropertyName" /> 
फिर

जब तुम, DefaultModelBinder अपने प्रपत्र सबमिट पोस्ट मूल्य को deserialize करने और दिए गए प्रकार के निर्माण और वस्तु (कम से कम यह कोशिश करेगा), अगर यह एक संबंधित प्रविष्टि नहीं मिल सकता है, तो संपत्ति शून्य हो जाएगी और यदि किसी प्रविष्टि की कोई संबंधित संपत्ति नहीं है, तो यह होगा अनदेखा (जब तक यो आपके पास अन्य पैरामीटर हैं)।

आप इसे article पढ़ सकते हैं, यह थोड़ा सा पुराना है, लेकिन यह अभी भी काफी सटीक है।

एक उदाहरण के रूप में:

मान लीजिए कि आप एक साधारण वस्तु है दो:

public class IndexModel 
{ 
    public string MyProperty { get; set; } 
    public bool MyCheckbox { get; set; } 
} 

एक साधारण controler:

public class TestingController : Controller 
{ 
    [OutputCache(Duration=0, NoStore = true)] 
    public ActionResult Index() 
    { 
     return View(new IndexModel { MyProperty = "hi" }); 
    } 

    [HttpPost] 
    [OutputCache(Duration=0, NoStore = true)] 
    public ActionResult Index(IndexModel model) 
    { 
     model.MyProperty += "!"; 
     ModelState.Clear(); 
     return View(model); 
    } 
} 

और एक साधारण दृश्य:

@model MvcApp.Models.IndexModel 

@using (Html.BeginForm()) 
{ 
    <div> 
     @Html.LabelFor(model => model.MyProperty)<p /> 
     @Html.TextBoxFor(model => model.MyProperty) 
    </div> 
    <div> 
     @Html.LabelFor(model => model.MyCheckbox)<p /> 
     @Html.CheckBoxFor(model => model.MyCheckbox) 
    </div> 

    <input type="submit" /> 
} 

आप देखेंगे, जब वाई कहां फॉर्म जमा करें, कि मॉडल पूरी तरह से बनाया गया है।

आप एक संपत्ति के वास्तविक मूल्य को प्रदर्शित नहीं करना चाहते हैं, लेकिन अभी भी जरूरत है यह कायम:

@Html.HiddenFor(model => model.MyProperty) 

यह एक छिपी हुई फ़ील्ड कि वापस तैनात किया जाएगा पैदा करते हैं और करेंगे, वजह, बनी रही।

हैप्पी कोडिंग!

+1

हाय लॉस्टड्रीमर, एक सबसे व्यापक और सहायक उत्तर। मैं इस बात से सहमत हूं कि मुझे जिस तरह से जाना है और पाब्लो राज्यों में मेरी पिछली टिप्पणी है। मैं दोनों उत्तरों को चिह्नित करना चाहता हूं समान रूप से उपयोगी हैं। यकीन नहीं है कि मैं यह कर सकता हूँ। गले फिर से धन्यवाद। ईडी – EdB

5

उस बड़े वस्तु को पूरी तरह से आवश्यक दृश्य में संग्रहीत कर रहा है?

View उस सामग्री पर कोई नियंत्रण नहीं है, इसलिए आप शायद उस डेटा को View पर नहीं भेजना चाहते हैं। ऐसा लगता है कि आप ViewState पर आधारित एक दिमागी सेट लागू कर रहे हैं, जो वास्तव में एमवीसी, आईएमएचओ के साथ बहुत अच्छी तरह फिट नहीं है। View और Controller के बीच

संचार ViewModels माध्यम से किया जाता है, और वहाँ आम तौर पर किसी भी बड़े धारावाहिक डेटा और बनाने है कि आगे और पीछे जब सर्वर के साथ बातचीत जाना स्टोर करने के लिए आवश्यकता नहीं है।

आप एक ViewModel उस दृश्य के लिए ही उपयोगी डेटा (क्षेत्र) का प्रतिनिधित्व करता है बना सकते हैं नहीं है, और अपने Action में वापस पोस्ट के दौरान ViewModel प्राप्त करने से है कि डेटा मिलता है, और बाद में सिंक्रनाइज़ जानकारी आप देखें से प्राप्त उस समय आप अपने एक्सएमएल से क्या लोड करते हैं?

+0

पाब्लो, आप सही हैं। मैंने अब एक व्यू मॉडल बनाया है और यह अच्छी तरह से काम करता है। मुझे अभी सभी व्यू मॉडल्स बनाने/बनाए रखने का एक अच्छा तरीका तैयार करने की आवश्यकता है क्योंकि एक दस्तावेज़ मॉडल पर काफी कुछ होगा। हालांकि मुझे लगता है कि यह मुझे सत्यापन की एक अतिरिक्त परत (एनोटेशन के माध्यम से) प्रदान करेगा और मुझे एक प्रदर्शन लाभ पर संदेह होगा क्योंकि कोई सिर्फ व्यूमोडल्स को चारों ओर ले जा रहा है। हालांकि मुझे अभी भी एक सत्र के माध्यम से दस्तावेज़ मॉडल को जारी रखने की आवश्यकता है या जब भी मुझे इसकी आवश्यकता होती है तो इसे deserialize। लेकिन यह सर्वर आधारित है और इस प्रकार नेटवर्क से अधिक नियंत्रित है। धन्यवाद। एड – EdB

+2

हाय पाब्लो, दोनों जवाब मेरे लिए अलग-अलग कारणों से सही हैं, लेकिन मैं दोनों पर टिक नहीं लगा सकता। हालांकि मैंने दोनों को चिह्नित किया है। बहुत धन्यवाद। एड – EdB

+0

उत्कृष्ट, धन्यवाद :) –

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