MVC 4 Views, агульны або канкрэтны?

Гэта мой першы раз, выкарыстоўваючы MVC, першы раз пішу вэб-дадатак, а таксама.

Да гэтага часу мне ўдалося мець прадстаўленне для спісу супрацоўнікаў, і выгляд рэдагавання для мадэлі Employee.

Калі б я меў 25 мадэляў, якія мне трэба адлюстроўваюцца ў выглядзе спісаў, і адрэдагаваныя, мне давядзецца стварыць 50 розных поглядаў?

ці ёсць спосаб мець адзін агульны спіс Прагляд і адзін агульны Edit View?

(Змяніць ніжэй)

Вырашана Прагляд спісу пытанне. Выбачайце за доўгі код.

Я стварыў <�моцны> ModelPropertyInfo клас, які апісвае ўласцівасці мадэлі. Пакуль я толькі дадаў ярлык, але я мог бы дадаць дадатковыя ўласцівасці, такія як «Фармат», «InputType», ...

// Model field information class. Used by views to display model info properly
public class ModelPropertyInfo
{
    public ModelPropertyInfo() { }

    public string Name { get; set; }
    public string Label { get; set; }

}

Тады <�моцны> ShowInListAttribute клас атрыбут для ўпрыгожвання толькі ўласцівасці мадэлі, якія я хачу, каб з'явіцца ў спісе

// Attribute class used to specify Labels for model fields
public class ShowInListAttribute : Attribute
{
    public ShowInListAttribute(string header)
    {
        Header = header;
    }

    public string Header { get; set; }
}

And a ModelBase class that all my models will inherit. This class will give the ability to get any property value from the class by passing its name as string

// Base class for all models
public class ModelBase
{
    public static List ModelProperties(Type modelType)
    {
        List result = new List();
        foreach (PropertyInfo pi in modelType.GetProperties())
        {
            ShowInListAttribute att = (ShowInListAttribute)pi.GetCustomAttributes(typeof(ShowInListAttribute), true).FirstOrDefault();
            if (att != null)
                result.Add(new ModelPropertyInfo { Label = att.Header, Name = pi.Name });
        }
        return result;
    }

    public object GetPropertyValue(string propName)
    {
        return this.GetType().GetProperty(propName).GetValue(this, null);
    }
}

Такім чынам, вось мой <�моцны> Супрацоўнік мадэль класа

[Table("Employee")]
public class Employee : ModelBase
{
    [Key]
    [DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
    public decimal ID { get; set; }

    [ShowInList("First Name")]
    public string FirstName { get; set; }

    [ShowInList("Last Name")]
    public string LastName { get; set; }

    public decimal DepartmentID { get; set; }

    [ShowInList("Department")]
    [DatabaseGeneratedAttribute(System.ComponentModel.DataAnnotations.Schema.DatabaseGeneratedOption.Computed)]
    public string DepartmentName { get; set; }
}

So, to put all the above to use, here's the Index method in my EmployeeController

public ActionResult Index()
{
    ViewBag.Columns = ModelBase.ModelProperties(typeof(Employee));
    ViewBag.Title = "Employee List";
    return View("ListShared", db.Employees.ToList());
}

І, нарэшце, вынік, то SharedListView, што я буду выкарыстоўваць для адлюстравання спісу любой мадэлі, якую я хачу

@using SharedListView.Models 

@model IEnumerable



@ViewBag.Title


@Html.ActionLink("Create New", "Create") <table> <tr> @foreach (ModelPropertyInfo col in ViewBag.Columns) { <th> @col.Label </th> } <th></th> </tr> @foreach (var item in Model) { <tr> @foreach (ModelPropertyInfo col in ViewBag.Columns) { <td width='100px'> @item.GetPropertyValue(col.Name).ToString() </td> } <td> @Html.ActionLink("Edit", "Edit", new { id=item.GetPropertyValue("ID") }) | @Html.ActionLink("Details", "Details", new { id=item.GetPropertyValue("ID") }) | @Html.ActionLink("Delete", "Delete", new { id=item.GetPropertyValue("ID") }) </td> </tr> } </table>

Тым не менш затрымаўся на агульнай кропцы гледжання рэдагавання, любая дапамога будзе ацэнена.

Зноў жа, прабачце за доўгае рэдагаванне.

0

8 адказы

Вам не трэба рабіць гэта. ASP.NET MVC падтрымлівае ContentFor метад і метад EditorFor. Так што ў вашым выпадку, вам трэба толькі да распрацоўкі сваіх мадэляў прагляду, а затым на ваш погляд, вы можаце выкарыстоўваць яго як

@Html.ContentFor(Model.Employee)//for display - that mean, it should be read-only
@Html.EditorFor(Model.Employee)//for editing.

You can see the post about that topic here

1
дададзена
На жаль, хлопцы. Я маю на ўвазе @ Html.ContentFor (мадэль)
дададзена аўтар thangchung, крыніца
ContentFor (Model.Employee)?
дададзена аўтар gush, крыніца
Мадэль мае тып Employee, так што я думаю, што вы мелі на ўвазе нешта накшталт @ Html.ContentFor (Employee.Name). І я не магу аштрафаваць памочніка ContentFor Html ў любым месцы.
дададзена аўтар gush, крыніца

Можна было б стварыць нейкі клас, які генеруе HTML для ўсіх розных тыпаў «формы уваходаў» вы будзеце мець патрэбу ў вашым дадатку. Затым дадаць здольнасць да класа атрымліваць дадзеныя з мадэляў (гэта значыць. Прымае радок з мадэлі і стварае увод тэксту са значэннем, усталяваным для гэтага радка .... ці ВЫБРАЦЬ выпадаючыя можа атрымаць усё гэта OPTIONS ад мадэлі, і г.д.).

Тады ўсе гэтыя формы ўваходы могуць быць створаны ўнутры мадэлі (выкарыстоўваючы свой клас) і можа быць напампаваны ў масіў, які перадаецца на ваш аднаго выгляду. Выгляд будзе змяшчаць усе навакольныя дзіў і іншыя HTML, але дзе-то ў прадстаўленні вы паклалі б маленькія «цыкл», які выводзіць змесціва вашага масіва. Гэта сапраўды MVC, у тым, што вы карыстаецеся толькі просты для цыклу з вашага пункту гледжання. І вашы мадэлі, у той ці іншай ступені могуць быць часткова адказныя пры прыняцці рашэння аб тым, як дадзеныя, калі адфарматаваны выходзіць з базы дадзеных (у дадзеным выпадку, форма уваходаў). Для таго, каб стылізаваць формы ўваходу, вы можаце захаваць стыль у файле CSS або ў верхняй частцы прадстаўлення.

У канчатковым рахунку, гэта залежыць ад будучага прыкладання. Гэта ідэя, калі ваша прыкладанне і мадэлі ўпісвацца ў добрую паўтаральную структуру. Але калі вы падазраяце, што часткі вашага прыкладання могуць развівацца, дзе часам вам можа спатрэбіцца погляд выглядаць зусім па-іншаму, ці вы хочаце атрымаць больш кантролю над тым, як вы наладжваеце кожны з гэтых згенераваных «формы уваходаў» ў поглядах, то вы, верагодна, будзеце ствараць большую колькасць праглядаў.

0
дададзена

Можна было б стварыць нейкі клас, які генеруе HTML для ўсіх розных тыпаў «формы уваходаў» вы будзеце мець патрэбу ў вашым дадатку. Затым дадаць здольнасць да класа атрымліваць дадзеныя з мадэляў (гэта значыць. Прымае радок з мадэлі і стварае увод тэксту са значэннем, усталяваным для гэтага радка .... ці ВЫБРАЦЬ выпадаючыя можа атрымаць усё гэта OPTIONS ад мадэлі, і г.д.).

Тады ўсе гэтыя формы ўваходы могуць быць створаны ўнутры мадэлі (выкарыстоўваючы свой клас) і можа быць напампаваны ў масіў, які перадаецца на ваш аднаго выгляду. Выгляд будзе змяшчаць усе навакольныя дзіў і іншыя HTML, але дзе-то ў прадстаўленні вы паклалі б маленькія «цыкл», які выводзіць змесціва вашага масіва. Гэта сапраўды MVC, у тым, што вы карыстаецеся толькі просты для цыклу з вашага пункту гледжання. І вашы мадэлі, у той ці іншай ступені могуць быць часткова адказныя пры прыняцці рашэння аб тым, як дадзеныя, калі адфарматаваны выходзіць з базы дадзеных (у дадзеным выпадку, форма уваходаў). Для таго, каб стылізаваць формы ўваходу, вы можаце захаваць стыль у файле CSS або ў верхняй частцы прадстаўлення.

У канчатковым рахунку, гэта залежыць ад будучага прыкладання. Гэта ідэя, калі ваша прыкладанне і мадэлі ўпісвацца ў добрую паўтаральную структуру. Але калі вы падазраяце, што часткі вашага прыкладання могуць развівацца, дзе часам вам можа спатрэбіцца погляд выглядаць зусім па-іншаму, ці вы хочаце атрымаць больш кантролю над тым, як вы наладжваеце кожны з гэтых згенераваных «формы уваходаў» ў поглядах, то вы, верагодна, будзеце ствараць большую колькасць праглядаў.

0
дададзена

Можна было б стварыць нейкі клас, які генеруе HTML для ўсіх розных тыпаў «формы уваходаў» вы будзеце мець патрэбу ў вашым дадатку. Затым дадаць здольнасць да класа атрымліваць дадзеныя з мадэляў (гэта значыць. Прымае радок з мадэлі і стварае увод тэксту са значэннем, усталяваным для гэтага радка .... ці ВЫБРАЦЬ выпадаючыя можа атрымаць усё гэта OPTIONS ад мадэлі, і г.д.).

Тады ўсе гэтыя формы ўваходы могуць быць створаны ўнутры мадэлі (выкарыстоўваючы свой клас) і можа быць напампаваны ў масіў, які перадаецца на ваш аднаго выгляду. Выгляд будзе змяшчаць усе навакольныя дзіў і іншыя HTML, але дзе-то ў прадстаўленні вы паклалі б маленькія «цыкл», які выводзіць змесціва вашага масіва. Гэта сапраўды MVC, у тым, што вы карыстаецеся толькі просты для цыклу з вашага пункту гледжання. І вашы мадэлі, у той ці іншай ступені могуць быць часткова адказныя пры прыняцці рашэння аб тым, як дадзеныя, калі адфарматаваны выходзіць з базы дадзеных (у дадзеным выпадку, форма уваходаў). Для таго, каб стылізаваць формы ўваходу, вы можаце захаваць стыль у файле CSS або ў верхняй частцы прадстаўлення.

У канчатковым рахунку, гэта залежыць ад будучага прыкладання. Гэта ідэя, калі ваша прыкладанне і мадэлі ўпісвацца ў добрую паўтаральную структуру. Але калі вы падазраяце, што часткі вашага прыкладання могуць развівацца, дзе часам вам можа спатрэбіцца погляд выглядаць зусім па-іншаму, ці вы хочаце атрымаць больш кантролю над тым, як вы наладжваеце кожны з гэтых згенераваных «формы уваходаў» ў поглядах, то вы, верагодна, будзеце ствараць большую колькасць праглядаў.

0
дададзена

Я хацеў бы прапанаваць вам мець такую ​​структуру для кожнага аб'екта мадэлі:

  1. ListView: Адлюстраванне спісу элемента. І стварыць клас ViewModel для кожнага элемента ў прадстаўленні
  2. CreateView: Выкарыстоўваецца пры стварэнні новага аб'екта. Акрамя таго, маючы клас ViewModel для гэтага
  3. EditView: такі ж, як CreateView, за выключэннем таго, што для рэжыму рэдагавання

Гэтая структура будзе ствараць шмат уяўленняў з ViewModel, якія выглядаюць аднолькава. Тым не менш, яны не з'яўляюцца, так як у прыродзе яны розныя для розных мэтаў. Структура палепшыць код у плане падзелу турботы, дапамагаюць у абслугоўванні. Лёгка працаваць.

0
дададзена
Я ведаю, што вы маеце на ўвазе, і я зрабіў нешта падобнае раней з ASP.NET. Аднак гэта выклікала галаўны боль, калі тып аб'екта расце, і асабліва, калі нам патрэбныя карыстацкае правіла/дзеянне, якое будзе прапаноўваць для кожнага тыпу. Менавіта таму я прапаную вам, што шлях
дададзена аўтар Thai Anh Duc, крыніца
Мне ўдалося стварыць прадстаўленне спісу, які можа адлюстроўваць любы аб'ект мадэлі любога тыпу. праверыць мой выбар. Яшчэ трэба высветліць ствараць і рэдагаваць віды. значна складаней, я думаю.
дададзена аўтар gush, крыніца

Ваша меркаванне будзе выкарыстоўваць мадэль для адлюстравання або рэдагавання дадзеных. Калі ў вас ёсць 25 розных мадэляў, кожны выгляд павінен мець іншую мадэль. Калі вы хочаце выкарыстоўваць толькі адну мадэль, у асноўным таму, што яны маюць падобныя ўласцівасці, гэта можа быць зроблена, але гэта не з'яўляецца ідэальным. Як гэта можна зрабіць, калі ўсе мадэлі маюць падобныя ўласцівасці, вы можаце ўключаць у сябе ўсе ўласцівасці ў адной мадэлі. Тады вы можаце проста выкарыстоўваць ўласцівасць, неабходныя ў іншых паданнях. Гэта не ідэальны спосаб зрабіць гэта. Кожны выгляд павінен мець сваю ўласную мадэль.

0
дададзена

Ваша меркаванне будзе выкарыстоўваць мадэль для адлюстравання або рэдагавання дадзеных. Калі ў вас ёсць 25 розных мадэляў, кожны выгляд павінен мець іншую мадэль. Калі вы хочаце выкарыстоўваць толькі адну мадэль, у асноўным таму, што яны маюць падобныя ўласцівасці, гэта можа быць зроблена, але гэта не з'яўляецца ідэальным. Як гэта можна зрабіць, калі ўсе мадэлі маюць падобныя ўласцівасці, вы можаце ўключаць у сябе ўсе ўласцівасці ў адной мадэлі. Тады вы можаце проста выкарыстоўваць ўласцівасць, неабходныя ў іншых паданнях. Гэта не ідэальны спосаб зрабіць гэта. Кожны выгляд павінен мець сваю ўласную мадэль.

0
дададзена

выпіска Knockout.js . Я напісаў дадатак, як тое, што вы кажаце, тым для збору дадзеных і прадстаўлення для рэдагавання асобных запісаў. выбивки робіць яго даволі лёгка інтэграваць частка рэдагавання поглядаў на прагляд калекцыі. Гэта сапраўды дапамагае мець некаторы ўяўленне пра wpf і Silverlight прывязкі дадзеных стыляў. Усе мае погляды цяпер выкарыстоўваць накаўт і я інтэграваць функцыі рэдагавання ў поглядах збору з прывязкай адпаведных дадзеных, выкарыстоўваючы бачную прывязку да вобласці рэдактара.

0
дададзена