MVC में ViewModel क्या है?


429

मैं ASP.NET MVC में नया हूँ। मुझे एक ViewModel के उद्देश्य को समझने में समस्या है।

एक ViewModel क्या है और हमें ASP.NET MVC एप्लिकेशन के लिए ViewModel की आवश्यकता क्यों है?

अगर मुझे इसके काम और स्पष्टीकरण के बारे में एक अच्छा उदाहरण मिलता है जो बेहतर होगा।


4
यह पोस्ट वह है जो आप खोज रहे हैं - "ASP.NET MVC ViewModel क्या है?"
यूसुबोव

6
यह लेख बहुत अच्छा लग रहा है: rachelappel.com/…
एंड्रयू

जवाबों:


607

एक view modelउस डेटा का प्रतिनिधित्व करता है जिसे आप अपने दृश्य / पृष्ठ पर प्रदर्शित करना चाहते हैं, चाहे वह स्थिर पाठ के लिए या इनपुट मानों (जैसे टेक्स्टबॉक्स और ड्रॉपडाउन सूची) के लिए उपयोग किया जाए जो डेटाबेस (या संपादित) में जोड़ा जा सकता है। यह आपके से कुछ अलग है domain model। यह देखने के लिए एक मॉडल है।

हम कहते हैं कि आपके पास एक Employeeवर्ग है जो आपके कर्मचारी डोमेन मॉडल का प्रतिनिधित्व करता है और इसमें निम्नलिखित गुण होते हैं (विशिष्ट पहचानकर्ता, पहला नाम, अंतिम नाम और बनाई गई तिथि):

public class Employee : IEntity
{
     public int Id { get; set; }

     public string FirstName { get; set; }

     public string LastName { get; set; }

     public DateTime DateCreated { get; set; }
}

दृश्य मॉडल डोमेन मॉडल से भिन्न होते हैं उस दृश्य मॉडल में केवल डेटा (गुणों द्वारा दर्शाया गया) होता है जिसे आप अपने दृश्य पर उपयोग करना चाहते हैं। उदाहरण के लिए, हम कहते हैं कि आप एक नया कर्मचारी रिकॉर्ड जोड़ना चाहते हैं, आपका दृश्य मॉडल इस तरह दिख सकता है:

public class CreateEmployeeViewModel
{
     public string FirstName { get; set; }

     public string LastName { get; set; }
}

जैसा कि आप देख सकते हैं कि इसमें केवल दो गुण हैं। ये दो गुण कर्मचारी डोमेन मॉडल में भी हैं। यह आप क्यों पूछ सकते हैं? Idदृश्य से सेट नहीं किया जा सकता है, यह कर्मचारी तालिका द्वारा उत्पन्न ऑटो हो सकता है। और DateCreatedसंग्रहीत कार्यविधि या आपके आवेदन की सेवा परत में भी सेट किया जा सकता है। इसलिए Idऔर DateCreatedदृश्य मॉडल में इसकी आवश्यकता नहीं है। जब आप किसी कर्मचारी के विवरण (एक कर्मचारी जो पहले से ही कब्जा कर लिया गया है) को स्थिर पाठ के रूप में देखते हैं, तो आप इन दोनों गुणों को प्रदर्शित करना चाह सकते हैं।

दृश्य / पृष्ठ लोड करते समय, आपके कर्मचारी नियंत्रक में एक्शन विधि इस दृश्य मॉडल का एक उदाहरण बनाएगी, यदि आवश्यक हो तो किसी भी फ़ील्ड को पॉप्युलेट करें, और फिर इस दृश्य मॉडल को दृश्य / पृष्ठ पर पास करें:

public class EmployeeController : Controller
{
     private readonly IEmployeeService employeeService;

     public EmployeeController(IEmployeeService employeeService)
     {
          this.employeeService = employeeService;
     }

     public ActionResult Create()
     {
          CreateEmployeeViewModel model = new CreateEmployeeViewModel();

          return View(model);
     }

     public ActionResult Create(CreateEmployeeViewModel model)
     {
          // Do what ever needs to be done before adding the employee to the database
     }
}

आपका दृश्य / पृष्ठ इस तरह दिख सकता है (यह मानते हुए कि आप उपयोग कर रहे हैं ASP.NET MVCऔर Razorदृश्य इंजन):

@model MyProject.Web.ViewModels.CreateEmployeeViewModel

<table>
     <tr>
          <td><b>First Name:</b></td>
          <td>@Html.TextBoxFor(m => m.FirstName, new { maxlength = "50", size = "50" })
              @Html.ValidationMessageFor(m => m.FirstName)
          </td>
     </tr>
     <tr>
          <td><b>Last Name:</b></td>
          <td>@Html.TextBoxFor(m => m.LastName, new { maxlength = "50", size = "50" })
              @Html.ValidationMessageFor(m => m.LastName)
          </td>
     </tr>
</table>

इस प्रकार मान्यता केवल FirstNameऔर पर ही होगी LastNameFluentValidation का उपयोग करना आपके पास इस तरह मान्य हो सकता है:

public class CreateEmployeeViewModelValidator : AbstractValidator<CreateEmployeeViewModel>
{
     public CreateEmployeeViewModelValidator()
     {
          RuleFor(m => m.FirstName)
               .NotEmpty()
               .WithMessage("First name required")
               .Length(1, 50)
               .WithMessage("First name must not be greater than 50 characters");

          RuleFor(m => m.LastName)
               .NotEmpty()
               .WithMessage("Last name required")
               .Length(1, 50)
               .WithMessage("Last name must not be greater than 50 characters");
     }
}

और डेटा एनोटेशन के साथ ऐसा लग सकता है:

public class CreateEmployeeViewModel : ViewModelBase
{
    [Display(Name = "First Name")]
    [Required(ErrorMessage = "First name required")]
    public string FirstName { get; set; }

    [Display(Name = "Last Name")]
    [Required(ErrorMessage = "Last name required")]
    public string LastName { get; set; }
}

याद रखने वाली महत्वपूर्ण बात यह है कि दृश्य मॉडल केवल उस डेटा का प्रतिनिधित्व करता है जिसे आप उपयोग करना चाहते हैं , और कुछ नहीं। आप सभी अनावश्यक कोड और सत्यापन की कल्पना कर सकते हैं यदि आपके पास 30 गुणों वाला एक डोमेन मॉडल है और आप केवल एक मूल्य को अपडेट करना चाहते हैं। इस परिदृश्य को देखते हुए आपके पास दृश्य मॉडल में केवल यही एक मूल्य / संपत्ति होगी और डोमेन ऑब्जेक्ट में मौजूद सभी गुण नहीं होंगे।

एक दृश्य मॉडल में केवल एक डेटाबेस तालिका से डेटा नहीं हो सकता है। यह दूसरी तालिका से डेटा को संयोजित कर सकता है। एक नया कर्मचारी रिकॉर्ड जोड़ने के बारे में ऊपर मेरा उदाहरण लें। केवल पहले और अंतिम नामों को जोड़ने के अलावा आप कर्मचारी विभाग को भी जोड़ना चाह सकते हैं। विभागों की यह सूची आपके Departmentsटेबल से आएगी । तो अब आपके पास एक दृश्य मॉडल में Employeesऔर Departmentsतालिकाओं से डेटा है । तब आपको अपने दृश्य मॉडल में निम्नलिखित दो गुणों को जोड़ने और इसे डेटा के साथ पॉप्युलेट करने की आवश्यकता होगी:

public int DepartmentId { get; set; }

public IEnumerable<Department> Departments { get; set; }

कर्मचारी डेटा (एक कर्मचारी जो पहले ही डेटाबेस में जोड़ा जा चुका है) का संपादन करते समय यह ऊपर दिए गए मेरे उदाहरण से बहुत भिन्न नहीं होगा। एक दृश्य मॉडल बनाएं, उदाहरण के लिए इसे कॉल करें EditEmployeeViewModel। केवल वह डेटा है जिसे आप इस दृश्य मॉडल में संपादित करना चाहते हैं, जैसे पहला नाम और अंतिम नाम। डेटा संपादित करें और सबमिट बटन पर क्लिक करें। मैं Idक्षेत्र के बारे में बहुत अधिक चिंता नहीं करूंगा क्योंकि Idमूल्य संभवतः URL में होगा, उदाहरण के लिए:

http://www.yourwebsite.com/Employee/Edit/3

इसे लें Idऔर इसे अपने रिपॉजिटरी लेयर से, अपने पहले नाम और अंतिम नाम मानों के साथ पास करें।

जब कोई रिकॉर्ड हटा रहा होता है, तो मैं आम तौर पर एडिट व्यू मॉडल के साथ उसी पथ का अनुसरण करता हूं। मेरे पास एक URL भी होगा, उदाहरण के लिए:

http://www.yourwebsite.com/Employee/Delete/3

जब पहली बार दृश्य लोड Idहोता है तो मुझे 3. का उपयोग करके डेटाबेस से कर्मचारी का डेटा मिलेगा । मैं तब अपने दृश्य / पृष्ठ पर केवल स्थिर पाठ प्रदर्शित करूंगा ताकि उपयोगकर्ता यह देख सके कि कर्मचारी को क्या हटाया जा रहा है। जब उपयोगकर्ता डिलीट बटन पर क्लिक करता है, तो मैं सिर्फ Id3 के मूल्य का उपयोग करूंगा और इसे मेरी रिपॉजिटरी लेयर में पास करूंगा। आपको केवल Idतालिका से रिकॉर्ड हटाने की आवश्यकता है ।

एक और बिंदु, आपको वास्तव में प्रत्येक कार्रवाई के लिए एक दृश्य मॉडल की आवश्यकता नहीं है। यदि यह सरल डेटा है तो केवल उपयोग के लिए ठीक होगा EmployeeViewModel। यदि यह जटिल दृश्य / पृष्ठ हैं और वे एक दूसरे से भिन्न हैं तो मेरा सुझाव है कि आप प्रत्येक के लिए अलग-अलग दृश्य मॉडल का उपयोग करें।

मुझे उम्मीद है कि यह किसी भी भ्रम को साफ करता है जो आपके पास दृश्य मॉडल और डोमेन मॉडल के बारे में था।


5
@ केनी: फिर इसे दिखाओ :) मैं जो कहना चाह रहा था वह कह सकता है कि आपके पास 50 गुणों के साथ एक डोमेन मॉडल है और आपके विचार में केवल 5 को प्रदर्शित करने की आवश्यकता है, तो केवल 5. प्रदर्शित करने के लिए सभी 50 गुणों को भेजने में कोई फायदा नहीं है
ब्रेंडन वोग

5
@BrendanVogt - आपने यह समझाते हुए एक अच्छा काम किया है, लेकिन मुझे यह समझ में नहीं आया कि लागत "सभी 50% भेजने" की क्या है। अन्य कोड पहले से ही सभी 50 गुणों के साथ एक मॉडल वस्तु पैदा कर दी है, है, और यह एक और वर्ग बनाए रखने के लिए सार्थक सिर्फ प्रतीत नहीं होता है नहीं 45 गुण भेजें - आप विशेष रूप से अगर हो सकता है भविष्य में उन 45 गुण में से किसी एक भेजना चाहते हैं।
केनी एविट जूल 17'13

5
@BrendanVogt - मुझे लगता है कि शायद LukLed का जवाब मुझे यह समझने में मदद करता है कि ये उपयोगी क्यों हो सकते हैं, विशेष रूप से कि एक ViewModel (कर सकते हैं) "... विभिन्न डेटाबेस संस्थाओं से मूल्यों को मिलाएं" [जहां मैं यह मान रहा हूं कि वाक्यांश सिर्फ सही थे " डेटाबेस इकाइयाँ "को" मॉडल ऑब्जेक्ट्स "से बदला जाना चाहिए]। लेकिन फिर भी, ViewModels को संबोधित करने के लिए कौन सी विशिष्ट समस्याएं थीं? क्या आपके पास कोई लिंक है? मुझे खुद कुछ नहीं मिला। [और मैं माफी माँगता हूँ अगर मैं तुम्हें लेने लगता हूँ!]
केनी एविट

1
मैंने अभी किसी को यह कहते हुए सुना है कि ViewModels एक संग्रह में कई संग्रह (या क्रॉस मॉडल गुण) भेजने का एक अच्छा तरीका है, उन्हें व्यूबाग में सामान किए बिना। मेरी समझ मे आ रहा है।
अय्याश

3
मुझे आलोचनात्मक होने के लिए खेद है लेकिन यह उत्तर दुर्भाग्य से अधूरा है। एक दृश्यदर्शी को केवल उसी रूप में परिभाषित करना जिसे आपको अपने पृष्ठ पर प्रदर्शित करने की आवश्यकता है, यह पूछने की तरह है कि "कार क्या है?" और एक उत्तर प्राप्त करना "इसका हवाई जहाज नहीं है"। वैसे यह सच है, लेकिन बहुत उपयोगी नहीं है। VM की अधिक सही परिभाषा "वह सब कुछ है जो आपको अपने पृष्ठ को प्रस्तुत करने की आवश्यकता है।" यदि आप नीचे तक पढ़ते हैं तो मैंने उन घटकों की पहचान की है जिन्हें आपको अपने वीएम के सही और आसानी से निर्माण की आवश्यकता है, कई मामलों में अपने मौजूदा डोमेन मॉडल और प्रस्तुति मॉडल का लाभ उठाते हैं।
सैम

133

दृश्य मॉडल एक वर्ग है जो विशिष्ट दृश्य में उपयोग किए जाने वाले डेटा मॉडल का प्रतिनिधित्व करता है। हम इस वर्ग को एक लॉगिन पृष्ठ के लिए एक मॉडल के रूप में उपयोग कर सकते हैं:

public class LoginPageVM
{
    [Required(ErrorMessage = "Are you really trying to login without entering username?")]
    [DisplayName("Username/e-mail")]
    public string UserName { get; set; }
    [Required(ErrorMessage = "Please enter password:)")]
    [DisplayName("Password")]
    public string Password { get; set; }
    [DisplayName("Stay logged in when browser is closed")]
    public bool RememberMe { get; set; }
}

इस दृश्य मॉडल का उपयोग करके आप दृश्य (रेजर दृश्य इंजन) को परिभाषित कर सकते हैं:

@model CamelTrap.Models.ViewModels.LoginPageVM

@using (Html.BeginForm()) {
    @Html.EditorFor(m => m);
    <input type="submit" value="Save" class="submit" />
}

और कार्य:

[HttpGet]
public ActionResult LoginPage()
{
    return View();
}

[HttpPost]
public ActionResult LoginPage(LoginPageVM model)
{
    ...code to login user to application...
    return View(model);
}

यह परिणाम उत्पन्न करता है (सत्यापन संदेश के साथ स्क्रीन सबमिट करने के बाद लिया जाता है):

जैसा कि आप देख सकते हैं, एक दृश्य मॉडल में कई भूमिकाएँ हैं:

  • देखें मॉडल दस्तावेज़ केवल फ़ील्ड्स को शामिल करके एक दृश्य है, जिसे देखने में प्रतिनिधित्व किया जाता है।
  • डेटा एनोटेशन या IDataErrorInfo का उपयोग करके दृश्य मॉडल में विशिष्ट सत्यापन नियम हो सकते हैं।
  • देखें मॉडल को परिभाषित करता है एक दृश्य (के लिए दिखना चाहिए कैसे LabelFor, EditorFor, DisplayForसहायकों)।
  • देखें मॉडल विभिन्न डेटाबेस संस्थाओं से मूल्यों को जोड़ सकते हैं।
  • आप व्यू मॉडल के लिए आसानी से डिस्प्ले टेम्प्लेट निर्दिष्ट कर सकते हैं और DisplayFor या EditorFor हेल्पर्स का उपयोग करके उन्हें कई स्थानों पर पुन: उपयोग कर सकते हैं।

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

public class UserVM {
    public int ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public bool IsAdministrator { get; set; }
    public string MothersName { get; set; }
}

रिट्रीवल:

var user = db.userRepository.GetUser(id);

var model = new UserVM() {
   ID = user.ID,
   FirstName = user.FirstName,
   LastName = user.LastName,
   IsAdministrator = user.Proviledges.IsAdministrator,
   MothersName = user.Mother.FirstName + " " + user.Mother.LastName
} 

I पतली उपयोगकर्ता। Mother.FirstName + "" + user.Mother.LastName, दृश्य मॉडल अंत में किया जाना चाहिए। सभी तर्क व्यू मॉडल एंड पर होने चाहिए।
कुरकुला

3
@ चंदन: मेरा मानना ​​है कि दृश्य मॉडल में सरल संयोजन किया जा सकता है। दो क्षेत्रों को उजागर करने का कोई कारण नहीं है, अगर उन्हें एक साथ प्रस्तुत किया जाना है।
लुकलेड

82

संपादित करें: मैंने अपने ब्लॉग पर इस उत्तर को अपडेट किया:

http://www.samwheat.com/post/The-function-of-ViewModels-in-MVC-web-development

मेरा जवाब थोड़ा लंबा है, लेकिन मुझे लगता है कि यह समझने के लिए कि सामान्य रूप से उपयोग किए जाने वाले मॉडल के अन्य प्रकार के दृश्य मॉडल की तुलना करना महत्वपूर्ण है कि वे अलग क्यों हैं और वे क्यों आवश्यक हैं।

संक्षेप में, और सीधे पूछे जाने वाले प्रश्न का उत्तर देने के लिए:

सामान्यतया, एक दृश्य मॉडल एक ऐसी वस्तु है जिसमें किसी दृश्य को प्रस्तुत करने के लिए आवश्यक सभी गुण और विधियाँ शामिल हैं। मॉडल के गुण अक्सर ग्राहक और ऑर्डर जैसी डेटा ऑब्जेक्ट से संबंधित होते हैं और इसके अलावा वे पृष्ठ या एप्लिकेशन से संबंधित गुण भी होते हैं जैसे उपयोगकर्ता नाम, एप्लिकेशन का नाम आदि। देखें मॉडल एक रेंडरिंग इंजन को पास करने के लिए एक सुविधाजनक ऑब्जेक्ट प्रदान करते हैं। एक html पेज बनाएं। एक दृश्य मॉडल का उपयोग करने के कई कारणों में से एक यह है कि दृश्य मॉडल कुछ प्रस्तुति कार्यों को यूनिट टेस्ट करने का एक तरीका प्रदान करते हैं जैसे उपयोगकर्ता इनपुट को संभालना, डेटा को मान्य करना, प्रदर्शन के लिए डेटा पुनर्प्राप्त करना आदि।

यहां एंटिटी मॉडल (a.ka. DTO's a.ka. मॉडल), प्रस्तुति मॉडल और व्यू मॉडल की तुलना की गई है।

डेटा ट्रांसफर ऑब्जेक्ट्स उर्फ ​​"मॉडल"

डेटा ट्रांसफर ऑब्जेक्ट (डीटीओ) एक वर्ग का गुण है जो डेटाबेस में टेबल स्कीमा से मेल खाता है। डीटीओ को डेटा स्टोर से डेटा को बंद करने के लिए उनके सामान्य उपयोग के लिए नामित किया गया है।
डीटीओ के लक्षण:

• व्यावसायिक वस्तुएं हैं - उनकी परिभाषा अनुप्रयोग डेटा पर निर्भर है।

• आमतौर पर केवल गुण होते हैं - कोई कोड नहीं।

• मुख्य रूप से डेटाबेस से डेटा को ट्रांसपोर्ट करने के लिए उपयोग किया जाता है।

• गुण डेटा स्टोर में किसी विशिष्ट तालिका पर फ़ील्ड के ठीक या निकट से मेल खाते हैं।

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

यहाँ दो उदाहरण हैं जो डीटीओ की तरह दिख सकते हैं:

public class Customer
{
    public int ID { get; set; }
    public string CustomerName { get; set; }
}


public class Order
{
    public int ID { get; set; }
    public int CustomerID { get; set; }
    public DateTime OrderDate { get; set; }
    public Decimal OrderAmount { get; set; }
}

प्रस्तुति मॉडल

एक प्रस्तुति मॉडल एक उपयोगिता वर्ग है जिसका उपयोग स्क्रीन या रिपोर्ट पर डेटा प्रस्तुत करने के लिए किया जाता है। प्रस्तुति मॉडल आमतौर पर जटिल डेटा संरचनाओं को मॉडल करने के लिए उपयोग किया जाता है जो कि कई डीटीओ के डेटा से तैयार किए जाते हैं। प्रस्तुति मॉडल अक्सर डेटा के एक असामान्य दृष्टिकोण का प्रतिनिधित्व करते हैं।

प्रस्तुति मॉडल के लक्षण:

• व्यावसायिक वस्तुएं हैं - उनकी परिभाषा अनुप्रयोग डेटा पर निर्भर है।

• ज्यादातर संपत्तियां होती हैं। कोड आमतौर पर स्वरूपण डेटा या डीटीओ से या में परिवर्तित करने तक सीमित है। प्रस्तुति मॉडल में व्यावसायिक तर्क नहीं होना चाहिए।

• अक्सर डेटा का एक असामान्य दृष्टिकोण प्रस्तुत करते हैं। यही है, वे अक्सर कई डीटीओ के गुणों को जोड़ते हैं।

• अक्सर डीटीओ की तुलना में एक अलग आधार प्रकार के गुण होते हैं। उदाहरण के लिए डॉलर की मात्रा को स्ट्रिंग्स के रूप में दर्शाया जा सकता है ताकि वे कॉमा और एक मुद्रा प्रतीक हो सकें।

• अक्सर परिभाषित किया जाता है कि उनका उपयोग कैसे किया जाता है और साथ ही साथ उनकी वस्तु विशेषताओं का उपयोग किया जाता है। दूसरे शब्दों में, ग्रिड को प्रस्तुत करने के लिए बैकिंग मॉडल के रूप में उपयोग किया जाने वाला एक सरल डीटीओ वास्तव में उस ग्रिड के संदर्भ में एक प्रस्तुति मॉडल है।

प्रस्तुति मॉडल का उपयोग "आवश्यकतानुसार" और "जहाँ आवश्यक हो" (जबकि डीटीओ आमतौर पर डेटाबेस स्कीमा से जुड़ा होता है) किया जाता है। एक प्रस्तुति मॉडल का उपयोग पूरे पृष्ठ के लिए डेटा, एक पृष्ठ पर एक ग्रिड, या एक पृष्ठ पर एक ग्रिड पर एक ड्रॉपडाउन मॉडल के लिए किया जा सकता है। प्रस्तुति मॉडल में अक्सर ऐसे गुण होते हैं जो अन्य प्रस्तुति मॉडल होते हैं। प्रस्तुति मॉडल अक्सर एकल-उपयोग के उद्देश्य के लिए बनाए जाते हैं जैसे कि एक पृष्ठ पर एक विशिष्ट ग्रिड को प्रस्तुत करना।

एक उदाहरण प्रस्तुति मॉडल:

public class PresentationOrder
{
    public int OrderID { get; set; }
    public DateTime OrderDate { get; set; }
    public string PrettyDate { get { return OrderDate.ToShortDateString(); } }
    public string CustomerName { get; set; }
    public Decimal OrderAmount { get; set; }
    public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } }
}

मॉडल देखें

एक दृश्य मॉडल एक प्रस्तुति मॉडल के समान है जिसमें एक दृश्य प्रस्तुत करने के लिए एक समर्थन वर्ग है। हालांकि यह एक प्रेजेंटेशन मॉडल या डीटीओ से अलग है कि इसका निर्माण कैसे किया जाता है। दृश्य मॉडल में अक्सर प्रस्तुति मॉडल और डीटीओ के समान गुण होते हैं और इस कारण से वे अक्सर एक दूसरे के लिए भ्रमित होते हैं।

दृश्य मॉडल के लक्षण:

• पृष्ठ या स्क्रीन को रेंडर करने के लिए उपयोग किए जाने वाले डेटा का एकल स्रोत हैं। आमतौर पर इसका मतलब है कि एक दृश्य मॉडल प्रत्येक संपत्ति को उजागर करेगा जो पृष्ठ पर किसी भी नियंत्रण को खुद को सही ढंग से प्रस्तुत करने की आवश्यकता होगी। दृश्य मॉडल को दृश्य के लिए डेटा का एकल स्रोत बनाने से इकाई परीक्षण के लिए इसकी क्षमता और मूल्य में काफी सुधार होता है।

कंपोजिट ऑब्जेक्ट्स होते हैं जिनमें ऐसे गुण होते हैं जो एप्लिकेशन डेटा के साथ-साथ उन गुणों से युक्त होते हैं जो एप्लिकेशन कोड द्वारा उपयोग किए जाते हैं। पुन: प्रयोज्य के लिए दृश्य मॉडल डिजाइन करते समय यह विशेषता महत्वपूर्ण है और नीचे दिए गए उदाहरणों में चर्चा की गई है।

• कंटेनर कोड। देखें मॉडल में आमतौर पर ऐसे तरीके होते हैं जो रेंडरिंग के दौरान कहलाते हैं और जब उपयोगकर्ता पेज के साथ इंटरैक्ट कर रहा होता है। यह कोड आमतौर पर ईवेंट हैंडलिंग, एनीमेशन, नियंत्रण की दृश्यता, स्टाइलिंग आदि से संबंधित है।

• डेटा प्राप्त करने या डेटाबेस सर्वर पर भेजने के उद्देश्य से व्यावसायिक सेवाओं को कॉल करने वाले कोड को शामिल करें। इस कोड को अक्सर गलती से एक नियंत्रक में रखा जाता है। एक नियंत्रक से व्यावसायिक सेवाओं को कॉल करना आमतौर पर इकाई परीक्षण के लिए दृश्य मॉडल की उपयोगिता को सीमित करता है। स्पष्ट होने के लिए, मॉडल को स्वयं व्यावसायिक तर्क नहीं होना चाहिए, लेकिन उन सेवाओं पर कॉल करना चाहिए जिनमें व्यावसायिक तर्क शामिल हैं।

• अक्सर ऐसे गुण होते हैं जो अन्य पृष्ठों या स्क्रीन के लिए अन्य दृश्य मॉडल होते हैं।

• "प्रति पृष्ठ" या "प्रति स्क्रीन" लिखा जाता है। एक विशिष्ट दृश्य मॉडल आमतौर पर हर पृष्ठ या स्क्रीन के लिए एक अनुप्रयोग में लिखा जाता है।

• आमतौर पर एक बेस क्लास से प्राप्त होता है क्योंकि अधिकांश पृष्ठ और स्क्रीन सामान्य गुण साझा करते हैं।

मॉडल संरचना देखें

जैसा कि पहले कहा गया है, दृश्य मॉडल समग्र वस्तुएं हैं, जिसमें वे एक ही वस्तु पर अनुप्रयोग गुणों और व्यावसायिक डेटा गुणों को जोड़ती हैं। आमतौर पर उपयोग किए जाने वाले अनुप्रयोग गुणों के उदाहरण जो दृश्य मॉडल पर उपयोग किए जाते हैं:

• गुण जो अनुप्रयोग स्थिति को प्रदर्शित करने के लिए उपयोग किए जाते हैं जैसे त्रुटि संदेश, उपयोगकर्ता नाम, स्थिति, आदि।

• गुणों का उपयोग प्रारूपण, प्रदर्शन, शैलीकरण या चेतन नियंत्रण के लिए किया जाता है।

• डेटा बाइंडिंग के लिए उपयोग की जाने वाली संपत्तियाँ जैसे सूची ऑब्जेक्ट और गुण जो मध्यवर्ती डेटा को धारण करते हैं जो उपयोगकर्ता द्वारा इनपुट किया जाता है।

निम्नलिखित उदाहरण दिखाते हैं कि दृश्य मॉडलों की समग्र प्रकृति क्यों महत्वपूर्ण है और हम कैसे कुशल और पुन: प्रयोज्य दृश्य मॉडल का सर्वोत्तम निर्माण कर सकते हैं।

मान लें कि हम एक वेब एप्लिकेशन लिख रहे हैं। एप्लिकेशन डिज़ाइन की आवश्यकताओं में से एक यह है कि पृष्ठ का शीर्षक, उपयोगकर्ता नाम और एप्लिकेशन नाम प्रत्येक पृष्ठ पर प्रदर्शित होना चाहिए। यदि हम एक प्रस्तुति ऑर्डर ऑब्जेक्ट प्रदर्शित करने के लिए एक पेज बनाना चाहते हैं, तो हम प्रस्तुति मॉडल को निम्नानुसार संशोधित कर सकते हैं:

public class PresentationOrder
{
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }
    public int OrderID { get; set; }
    public DateTime OrderDate { get; set; }
    public string PrettyDate { get { return OrderDate.ToShortDateString(); } }
    public string CustomerName { get; set; }
    public Decimal OrderAmount { get; set; }
    public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } }
}

यह डिज़ाइन काम कर सकता है ... लेकिन क्या होगा अगर हम एक ऐसा पेज बनाना चाहते हैं जो आदेशों की सूची प्रदर्शित करे? PageTitle, UserName, और ApplicationName गुण दोहराए जाएंगे और उनके साथ काम करने में अनिच्छुक हो जाएंगे। इसके अलावा, क्या होगा यदि हम कक्षा के निर्माण में कुछ पृष्ठ-स्तरीय तर्क को परिभाषित करना चाहते हैं? हम अब ऐसा नहीं कर सकते हैं कि यदि हम प्रत्येक आदेश के लिए एक उदाहरण बनाते हैं जो प्रदर्शित किया जाएगा।

वंशानुक्रम पर रचना

यहां एक तरीका है कि हम ऑर्डर प्रेजेंटेशन मॉडल को फिर से फैक्टर कर सकते हैं जैसे कि यह एक सच्चा व्यू मॉडल बन जाता है और यह एक प्रेजेंटेशनऑडर ऑब्जेक्ट या प्रेजेंटेशनऑर्डर ऑब्जेक्ट्स के कलेक्शन को प्रदर्शित करने के लिए उपयोगी होगा:

public class PresentationOrderVM
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business properties
    public PresentationOrder Order { get; set; }
}


public class PresentationOrderVM
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business properties
    public List<PresentationOrder> Orders { get; set; }
}

उपरोक्त दो वर्गों को देखते हुए हम देख सकते हैं कि एक दृश्य मॉडल के बारे में सोचने का एक तरीका यह है कि यह एक प्रस्तुति मॉडल है जिसमें संपत्ति के रूप में एक और प्रस्तुति मॉडल शामिल है। शीर्ष स्तर की प्रस्तुति मॉडल (अर्थात दृश्य मॉडल) में ऐसे गुण होते हैं जो पृष्ठ या एप्लिकेशन के लिए प्रासंगिक होते हैं जबकि प्रस्तुति मॉडल (संपत्ति) में ऐसे गुण होते हैं जो एप्लिकेशन डेटा के लिए प्रासंगिक होते हैं।

हम अपने डिजाइन को एक कदम आगे ले जा सकते हैं और एक बेस व्यू मॉडल क्लास बना सकते हैं जिसका इस्तेमाल न केवल प्रेजेंटेशन ऑर्डर्स के लिए किया जा सकता है, बल्कि किसी अन्य क्लास के लिए भी किया जा सकता है:

public class BaseViewModel
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }
}

अब हम अपनी प्रस्तुति को इस तरह सरल बना सकते हैं:

public class PresentationOrderVM : BaseViewModel
{
    // Business properties
    public PresentationOrder Order { get; set; }
}

public class PresentationOrderVM : BaseViewModel
{
    // Business properties
    public List<PresentationOrder> Orders { get; set; }
}

हम अपने BaseViewModel को सामान्य बनाकर और भी अधिक प्रयोग करने योग्य बना सकते हैं:

public class BaseViewModel<T>
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business property
    public T BusinessObject { get; set; }
}

अब हमारे कार्यान्वयन सरल हैं:

public class PresentationOrderVM : BaseViewModel<PresentationOrder>
{
    // done!
}

public class PresentationOrderVM : BaseViewModel<List<PresentationOrder>>
{
    // done!
}

2
सैम थैंक यू !! इसने मुझे बहु-आयामी इकाई की पूरी तरह से सहायता करने में मदद की जो एक है: व्यू-मॉडल। मैं एमवीसी आर्किटेक्चर सीखने वाला एक कॉलेज छात्र हूं, और इसने डेवलपर के सामने सक्षम क्षमताओं का एक गुच्छा स्पष्ट किया है। अगर मैं कर सकता तो मैं आपके जवाब के आगे एक स्टार लगा देता।
शेफ_कोड

1
@ 'देखें' मॉडल में अक्सर प्रस्तुति मॉडल और डीटीओ के समान गुण होते हैं और इस कारण से वे अक्सर एक दूसरे के लिए भ्रमित होते हैं। ' इसका मतलब यह है कि वे आमतौर पर प्रस्तुति मॉडल के बजाय उपयोग किया जाता है , या वे प्रस्तुति मॉडल / dtos शामिल करने के लिए हैं?
अलेक्जेंडर डर्क

2
@AlexanderDerck उनका उपयोग विभिन्न उद्देश्यों के लिए किया जाता है। वे एक दूसरे के लिए उलझन में हैं (गलती से)। नहीं, आप आमतौर पर एक दृश्य मॉडल के स्थान पर एक अध्यक्ष मॉडल का उपयोग नहीं करेंगे। बहुत अधिक सामान्य है कि वीएम में "प्रस्तुति मॉडल" शामिल है MyViewModel<MyPresModel>
सैम

2
@Sam मॉडलिंग ऑब्जेक्ट्स को लाइव ऑब्जेक्ट माना जाता है उदा nhibernate मॉडल .. इसलिए BusinessObject होने से हम मॉडल / लाइव ऑब्जेक्ट को सीधे दृश्य में उजागर नहीं कर रहे हैं? डेटाबेस के राज्य को सीधे संशोधित करने के लिए व्यावसायिक वस्तु का उपयोग किया जा सकता है? इसके अलावा, नेस्टेड व्यू मॉडल के बारे में क्या? इसके लिए कई व्यावसायिक वस्तु गुणों की आवश्यकता होगी, है ना?
मुहम्मद अली

22

यदि आपके पास दृश्य के लिए विशिष्ट गुण हैं, और DB / सेवा / डेटा स्टोर से संबंधित नहीं है, तो ViewModels का उपयोग करना एक अच्छा अभ्यास है। कहते हैं, आप एक DB फ़ील्ड (या दो) के आधार पर चयनित एक चेकबॉक्स छोड़ना चाहते हैं, लेकिन DB फ़ील्ड स्वयं एक बूलियन नहीं है। हालांकि इन गुणों को मॉडल में स्वयं बनाना संभव है और इसे बाइंडिंग से डेटा तक छिपा कर रखा जाता है, हो सकता है कि आप ऐसे क्षेत्रों और लेन-देन की मात्रा के आधार पर मॉडल को अव्यवस्थित करना न चाहें।

यदि बहुत कम दृश्य-विशिष्ट डेटा और / या परिवर्तन हैं, तो आप स्वयं मॉडल का उपयोग कर सकते हैं


19

मैंने सभी पोस्ट नहीं पढ़े लेकिन हर उत्तर में एक अवधारणा याद आ रही है जिसने वास्तव में मुझे "इसे प्राप्त करने" में मदद की ...

यदि कोई मॉडल डेटाबेस तालिका के समान है , तो एक ViewModel एक डेटाबेस दृश्य के समान है - एक दृश्य आमतौर पर या तो एक तालिका से छोटी मात्रा में डेटा लौटाता है, या, कई तालिकाओं से डेटा के जटिल सेट (जुड़ता है)।

मैं व्यू / फॉर्म में जानकारी पास करने के लिए ViewModels का उपयोग कर खुद को ढूंढता हूं, और फिर उस डेटा को एक वैध मॉडल में स्थानांतरित करता हूं जब फॉर्म नियंत्रक पर वापस पोस्ट करता है - सूची (IEnumerable) को संग्रहीत करने के लिए भी बहुत आसान है।


11

MVC के पास एक व्यूमॉडल नहीं है: इसमें एक मॉडल, दृश्य और नियंत्रक है। एक viewmodel MVVM (मॉडल-व्यू-व्यूमॉडल) का हिस्सा है। MVVM प्रेजेंटेशन मॉडल से लिया गया है और WPF में लोकप्रिय है। MVVM में एक मॉडल भी होना चाहिए, लेकिन ज्यादातर लोग उस पैटर्न के बिंदु को पूरी तरह से याद करते हैं और उनके पास केवल एक दृश्य और एक दृश्यदर्शी होगा। एमवीसी में मॉडल एमवीवीएम के मॉडल के समान है।

MVC में प्रक्रिया को 3 अलग-अलग जिम्मेदारियों में विभाजित किया जाता है:

  • उपयोगकर्ता को डेटा प्रस्तुत करने के लिए दृश्य जिम्मेदार है
  • पेज फ्लो के लिए एक कंट्रोलर जिम्मेदार होता है
  • एक मॉडल व्यावसायिक तर्क के लिए जिम्मेदार है

MVC वेब अनुप्रयोगों के लिए बहुत उपयुक्त नहीं है। यह डेस्कटॉप एप्लिकेशन बनाने के लिए स्मॉलटाक द्वारा पेश किया गया एक पैटर्न है। एक वेब वातावरण पूरी तरह से अलग व्यवहार करता है। यह डेस्कटॉप विकास से 40 साल पुरानी अवधारणा को कॉपी करने और एक वेब एनवायरमेंट में पेस्ट करने के लिए बहुत अधिक समझ में नहीं आता है। हालांकि, बहुत से लोग सोचते हैं कि यह ठीक है, क्योंकि उनका आवेदन सही मूल्यों को संकलित करता है और वापस करता है। अर्थात्, मेरी राय में, एक निश्चित डिजाइन विकल्प को ठीक घोषित करने के लिए पर्याप्त नहीं है।

एक वेब अनुप्रयोग में एक मॉडल का एक उदाहरण हो सकता है:

public class LoginModel
{
    private readonly AuthenticationService authentication;

    public LoginModel(AuthenticationService authentication)
    {
        this.authentication = authentication;
    }

    public bool Login()
    {
        return authentication.Login(Username, Password);
    }

    public string Username { get; set; }
    public string Password { get; set; }
}

नियंत्रक इसका उपयोग इस तरह कर सकता है:

public class LoginController
{
    [HttpPost]
    public ActionResult Login(LoginModel model)
    {
        bool success = model.Login();

        if (success)
        {
            return new RedirectResult("/dashboard");
        }
        else
        {
            TempData["message"] = "Invalid username and/or password";
            return new RedirectResult("/login");
        }
    }
}

आपके नियंत्रक तरीके और आपके मॉडल छोटे, आसानी से परीक्षण करने योग्य और बिंदु पर होंगे।


MVVM वास्तुकला में अंतर्दृष्टि के लिए धन्यवाद, लेकिन MVC ठीक क्यों नहीं है? आपका तर्क संदिग्ध है और पक्षपात के लिए संदिग्ध है। मुझे लगता है कि एमवीवीएम के बारे में कुछ नहीं पता है, लेकिन अगर एमवीसी जैसी वास्तुकला 50k कोड लिखने के लिए आउट-आउट के साथ व्यवहार की नकल कर सकती है, तो बड़ी बात क्या है?
शेफ_कोड

@Chef_Code: यह संदेहास्पद या पक्षपात नहीं है: केवल एमवीसी के बारे में मूल पेपर पढ़ें। स्रोत पर वापस जाना नेत्रहीन बिना सवाल (उर्फ "सर्वोत्तम प्रथाओं") के झुंड का पालन करने से बेहतर है। MVC बहुत छोटी इकाइयों के लिए होता है: जैसे स्क्रीन पर एक बटन एक मॉडल, दृश्य और नियंत्रक से बना होता है। वेब-एमवीसी में पूरे पृष्ठ में एक नियंत्रक, एक मॉडल और एक दृश्य होता है। मॉडल और दृश्य को जोड़ा जाना चाहिए, ताकि मॉडल में परिवर्तन तुरंत दृश्य में दिखाई दे और इसके विपरीत। नकल करना बहुत बड़ी बात है। एक आर्किटेक्चर यह डेवलपर्स के लिए झूठ नहीं होना चाहिए।
जेरोन

1
@ जेरोइन संक्षिप्त एमवीसी चोरी और मंगाई गई है। हाँ MVC में एक VM नहीं है, लेकिन इसमें एक रिपॉजिटरी या एक सेवा परत नहीं है और उन वस्तुओं का व्यापक रूप से वेब साइटों में उपयोग किया जाता है। मेरा मानना ​​है कि ओपी पूछ रहा है कि "मैं एमवीसी में वीएम का परिचय और उपयोग कैसे करूं"। एमवीसी के नए अर्थ में एक मॉडल ऐसा नहीं है जहां व्यावसायिक तर्क है। व्यावसायिक तर्क MVC या MVVM का उपयोग करके वेब या डेस्कटॉप ऐप के लिए एक सेवा स्तर में है। शब्द मॉडल उन व्यावसायिक वस्तुओं का वर्णन करता है जो सेवा स्तर से / से पास की जाती हैं। ये परिभाषा एमवीसी के मूल विवरण से काफी अलग हैं।
सैम

1
@Sam वह सब कुछ नहीं है जो एक वेबसाइट का हिस्सा है, इसे MVC का हिस्सा कहा जा सकता है। MVC का कोई नया अर्थ नहीं है। सही अर्थ है और "कुछ पूरी तरह से असंबंधित है जो लोग एमवीसी के साथ भ्रमित करते हैं" -मिनींग। यह कहना कि मॉडल व्यावसायिक तर्क के लिए ज़िम्मेदार है, व्यवसाय तर्क तर्क मॉडल में कोडित नहीं है। अधिकांश समय मॉडल अनुप्रयोग के लिए एक मुखौटा के रूप में कार्य करता है।
फिरोज

Microsoft के MVC में मुझे जो मुख्य दोष दिखाई देता है, वह एक दृश्य के साथ एक मॉडल का लॉकिंग है। यह पिछले 20 वर्षों से एन-टीयर डिजाइन में चल रहे इस अलगाव के पूरे उद्देश्य को ही पराजित करता है। उन्होंने 2002 में हमें "WebForms" का उपयोग करने के लिए मजबूर करने में अपना समय बर्बाद कर दिया, जो वेब दुनिया पर फहराया गया एक अन्य डेस्कटॉप-प्रेरित मॉडल था। अब उन्होंने कहा है कि वेब देव के लिए इस नए प्रतिमान पर फिर से एक और डेस्कटॉप मॉडल फहराया गया है। इस बीच Google और अन्य विशालकाय क्लाइंट-साइड मॉडल बना रहे हैं जो इसे अलग करते हैं। Im सोच पुराने एएसपी VBScript 1998 से उनके truest वेब देव प्रणाली था।
स्टोकली

11

देखें मॉडल एक सरल वर्ग है जिसमें एक से अधिक वर्ग गुण हो सकते हैं। हम इसका उपयोग सभी आवश्यक गुणों को प्राप्त करने के लिए करते हैं, जैसे कि मेरे पास दो कक्षाएं हैं छात्र और विषय

Public class Student
{
public int Id {get; set;}
public string Name {get; set;}
}  
Public class Subject
{
public int SubjectID {get; set;}
public string SubjectName {get; set;}
}

अब हम रिकॉर्ड छात्र का नाम और विषय का नाम दृश्य में (एमवीसी में) प्रदर्शित करना चाहते हैं, लेकिन यह संभव नहीं है:

 @model ProjectName.Model.Student  
 @model ProjectName.Model.Subject

उपरोक्त कोड एक त्रुटि फेंक देगा ...

अब हम एक वर्ग बनाते हैं और इसे कोई भी नाम दे सकते हैं, लेकिन "XyzViewModel" यह प्रारूप समझने में आसान बना देगा। यह विरासत की अवधारणा है। अब हम निम्नलिखित नाम के साथ एक तीसरा वर्ग बनाते हैं:

public class StudentViewModel:Subject
{
public int ID {get; set;}
public string Name {get; set;}
}

अब हम View में इस ViewModel का उपयोग करते हैं

@model ProjectName.Model.StudentViewModel

अब हम व्यू में छात्र व्यू और विरासत में मिली क्लास की सभी संपत्तियों तक पहुँचने में सक्षम हैं।


10

बहुत सारे बड़े उदाहरण, मुझे स्पष्ट और खस्ता तरीके से समझाते हैं।

ViewModel = मॉडल जो दृश्य की सेवा करने के लिए बनाया गया है।

ASP.NET MVC दृश्य में एक से अधिक मॉडल नहीं हो सकते हैं, इसलिए यदि हमें एक से अधिक मॉडलों के गुणों को दृश्य में प्रदर्शित करने की आवश्यकता है, तो यह संभव नहीं है। ViewModel इस उद्देश्य को पूरा करता है।

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

दृश्य मॉडल के कुछ उदाहरण नीचे हैं

  • एक दृश्य पृष्ठ में संस्थाओं से अधिक डेटा को सूचीबद्ध करने के लिए - हम एक दृश्य मॉडल बना सकते हैं और उन सभी संस्थाओं के गुण हैं जिनके लिए हम डेटा सूचीबद्ध करना चाहते हैं। उन डेटाबेस संस्थाओं से जुड़ें और मॉडल गुण सेट करें और एक सारणीबद्ध रूप में विभिन्न संस्थाओं का डेटा दिखाने के लिए दृश्य पर वापस लौटें
  • दृश्य मॉडल एकल इकाई के केवल विशिष्ट क्षेत्रों को परिभाषित कर सकता है जो दृश्य के लिए आवश्यक है।

ViewModel का उपयोग सम्मिलित करने के लिए भी किया जा सकता है, एक से अधिक संस्थाओं में रिकॉर्ड अपडेट करें हालांकि ViewModel का मुख्य उपयोग एक ही दृश्य में कई संस्थाओं (मॉडल) से कॉलम प्रदर्शित करना है।

ViewModel बनाने का तरीका मॉडल बनाने के समान है, Viewmodel के लिए दृश्य बनाने का तरीका मॉडल के लिए दृश्य बनाने के समान है।

यहाँ ViewModel का उपयोग करके सूची डेटा का एक छोटा सा उदाहरण दिया गया है ।

आशा है कि यह उपयोगी होगा।


6

ViewModel वर्कअराउंड है जो MVC फ्रेमवर्क के वैचारिक अनाड़ीपन को पैच करता है। यह 3-लेयर मॉडल-व्यू-कंट्रोलर आर्किटेक्चर में 4th लेयर का प्रतिनिधित्व करता है। जब मॉडल (डोमेन मॉडल) दृश्य के लिए बहुत बड़ा (2-3 फ़ील्ड से बड़ा) उपयुक्त नहीं है, तो हम इसे देखने के लिए पास करने के लिए छोटे ViewModel बनाते हैं।


1

एक दृश्य मॉडल डेटा का एक वैचारिक मॉडल है। इसका उपयोग उदाहरण के लिए या तो एक सबसेट प्राप्त करना है या विभिन्न तालिकाओं से डेटा को संयोजित करना है।

आप केवल विशिष्ट गुण चाहते हैं, इसलिए यह आपको केवल उन अतिरिक्त लोडों और अतिरिक्त अनावश्यक संपत्तियों को लोड करने की अनुमति देता है


1
  • ViewModel में फ़ील्ड्स होते हैं जिन्हें दृश्य में दिखाया जाता है (लेबलफ़ॉर के लिए, EditorFor, DisplayFor सहायकों के लिए)
  • ViewModel में डेटा एनोटेशन या IDataErrorInfo का उपयोग करके विशिष्ट सत्यापन नियम हो सकते हैं।
  • ViewModel में विभिन्न डेटा मॉडल या डेटा स्रोत से कई निकाय या ऑब्जेक्ट हो सकते हैं।

डिजाइनिंग ViewModel

public class UserLoginViewModel 
{ 
[Required(ErrorMessage = "Please enter your username")] 
[Display(Name = "User Name")]
[MaxLength(50)]
public string UserName { get; set; }
 [Required(ErrorMessage = "Please enter your password")]
 [Display(Name = "Password")]
 [MaxLength(50)]
 public string Password { get; set; } 
} 

दृश्य में दृश्य प्रस्तुत करना

@model MyModels.UserLoginViewModel 
@{
 ViewBag.Title = "User Login";
 Layout = "~/Views/Shared/_Layout.cshtml";
}
@using (Html.BeginForm())
{
<div class="editor-label">
 @Html.LabelFor(m => m.UserName)
</div>
<div class="editor-field">
 @Html.TextBoxFor(m => m.UserName)
 @Html.ValidationMessageFor(m => m.UserName)
</div>
<div class="editor-label">
 @Html.LabelFor(m => m.Password)
</div>
<div class="editor-field">
 @Html.PasswordFor(m => m.Password)
 @Html.ValidationMessageFor(m => m.Password)
</div>
<p>
 <input type="submit" value="Log In" />
</p>
</div>
}

कार्य के साथ कार्य करना

public ActionResult Login()
{ 
return View();
}
[HttpPost]
public ActionResult Login(UserLoginViewModel user)
{
// To acces data using LINQ
DataClassesDataContext mobjentity = new DataClassesDataContext();
 if (ModelState.IsValid) 
{ 
try
 {
 var q = mobjentity.tblUsers.Where(m => m.UserName == user.UserName && m.Password == user.Password).ToList(); 
 if (q.Count > 0) 
 { 
 return RedirectToAction("MyAccount");
 }
 else
 {
 ModelState.AddModelError("", "The user name or password provided is incorrect.");
 }
 }
 catch (Exception ex)
 {
 } 
 } 
 return View(user);
} 
  1. ViewModel में केवल वे फ़ील्ड / डेटा डालें जिन्हें आप दृश्य / पृष्ठ पर प्रदर्शित करना चाहते हैं।
  2. चूंकि दृश्य ViewModel के गुणों को दोहराता है, इसलिए यह प्रतिपादन और रखरखाव के लिए आसान है।
  3. ViewModel अधिक जटिल हो जाने पर मैपर का उपयोग करें।

1

व्यू मॉडल वह क्लास है जिसे हम व्यू पर डेटा रेंडर करने के लिए उपयोग कर सकते हैं। मान लीजिए कि आपके पास दो संस्थाएँ हैं प्लेस और कैशे कैटिगरी और आप एकल मॉडल का उपयोग करके दोनों संस्थाओं से डेटा एक्सेस करना चाहते हैं तो हम ViewModel का उपयोग करते हैं।

  public class Place
    {
       public int PlaceId { get; set; }
        public string PlaceName { get; set; }
        public string Latitude { get; set; }
        public string Longitude { get; set; }
        public string BestTime { get; set; }
    }
    public class Category
    {
        public int ID { get; set; }
        public int? PlaceId { get; set; }
        public string PlaceCategoryName { get; set; }
        public string PlaceCategoryType { get; set; }
    }
    public class PlaceCategoryviewModel
    {
        public string PlaceName { get; set; }
        public string BestTime { get; set; }
        public string PlaceCategoryName { get; set; }
        public string PlaceCategoryType { get; set; }
    }

इसलिए ऊपर के उदाहरण में प्लेस और श्रेणी दो अलग-अलग इकाइयाँ हैं और प्लेस कैटररी व्यूमॉडल ViewModel है जिसे हम व्यू पर उपयोग कर सकते हैं।


आपके उदाहरण इतने स्पष्ट नहीं हैं। ऊपर कहा गया है कि एक ViewModel अपने दृश्य में डेटा जोड़ता है। यदि आप BlipAjax में ViewModels को देखते हैं तो आपको ऐसी कक्षाएं दिखाई देती हैं जो इसके लिए एकदम उपयुक्त हैं।
हरमन वान डेर ब्लूम

0

यदि आप कोड का अध्ययन करना चाहते हैं, तो ViewModels के साथ "बेसलाइन" वेब एप्लिकेशन को कैसे सेटअप करें मैं इस कोड को GitHub: https://github.com/ajsaulsberry/BlipAjax पर डाउनलोड करने की सलाह दे सकता हूं । मैंने बड़े उद्यम अनुप्रयोगों का विकास किया। जब आप एक अच्छा आर्किटेक्चर सेटअप करने के लिए इसकी समस्याग्रस्त करते हैं जो यह सब "ViewModel" कार्यक्षमता को संभालता है। मुझे लगता है कि BlipAjax के साथ शुरू करने के लिए आपके पास एक बहुत अच्छी "आधार रेखा" होगी। यह सिर्फ एक साधारण वेबसाइट है, लेकिन इसकी सादगी में बहुत अच्छा है। मैं जिस तरह से वे वास्तव में आवेदन में जरूरत whats पर इंगित करने के लिए अंग्रेजी भाषा का इस्तेमाल किया पसंद है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.