MVC 4 Adnotacje danych "Display" Atrybut

Zaczynam od MVC 4 (Razor view engine). (Sądzę, że może to dotyczyć także MVC 3 i wcześniejszych). Zastanawiam się, czy istnieje jakaś korzyść z używania adnotacji danych DisplayAttribute w widoku, a jedynie zapisywanie ciągu bezpośrednio w kodzie HTML. Na przykład, gdybym miał następujący model:MVC 4 Adnotacje danych "Display" Atrybut

public class Thing 
{ 
    public string WildAndCrazyProperty { get; set; } 
}

... będzie tam żadnych korzyści w opisywanie właściwości jak:

[Display(Name = "Wild and Crazy")] 
    public string WildAndCrazyProperty { get; set; }

... io moim znaczników być:

<html> 
    <body> 
     <div>@Html.DisplayNameFor(modelItem => modelItem.WildAndCrazyProperty)</div> 
     <div>@Html.DisplayFor(modelItem => modelItem.WildAndCrazyProperty)</div> 
    </body> 
</html>

... versus nie posiadające adnotacji i robi:

<html> 
    <body> 
     <div>Wild and Crazy</div> 
     <div>@Html.DisplayFor(modelItem => modelItem.WildAndCrazyProperty)</div> 
    </body> 
</html>

Powód, dla którego nie wspomniałem w tym przypadku Html.LabelFor, ponieważ dane właściwości są wyświetlane jako statyczne (tj. nieedytowalny) tekst na stronie. Dane nigdy nie będą edytowalne na tej stronie, więc nie ma potrzeby, aby używać Html.TextBoxFor w drugim <div> i następnie użyć Html.LabelFor, aby poprawnie powiązać etykietę z tym polem tekstowym.

Źródło

2012-10-04 Kenneth K.

Jeśli dwa różne widoki współużytkują ten sam model (na przykład, być może jeden jest dla wersji mobilnej, a drugi jest regularny), może być miło mieć ciąg znajdujący się w jednym miejscu: jako metadane w ViewModel.

Dodatkowo, jeśli masz odziedziczoną wersję modelu, która wymagała innego wyświetlacza, może być przydatna. Na przykład:

public class BaseViewModel 
{ 
    [Display(Name = "Basic Name")] 
    public virtual string Name { get; set; } 
} 

public class OtherViewModel : BaseViewModel 
{ 
    [Display(Name = "Customized Inherited Name")] 
    public override string Name { get; set; } 
}

Muszę przyznać, że ten przykład jest całkiem wymyślone ...

Są to najlepsze argumenty przemawiające za pomocą atrybutu, że mogę wymyślić. Moim osobistym zdaniem jest to, że w większości tego rodzaju rzeczy najlepiej zostawić na znak.

Źródło

2012-10-04 21:00:24 eouw0o83hf

I tak właśnie się wychylam. Wygląda na to, że w części kodu, która faktycznie wyświetla się, chciałbyś czegoś, co jest rzeczywiście bardziej typem wyświetlania. Konieczność ponownej kompilacji projektu, aby zmienić nagłówek lub dwa, wydaje się niepotrzebna. –

Całkowicie zgadzam się na punkt ponownej kompilacji. Czuję, że nawet gdybyś musiał użyć tego modelu w wielu widokach, zalety umieszczania tych danych w atrybucie nie przewyższają wad. – eouw0o83hf

Bardzo podoba mi się koncepcja, która kryje się za tą odpowiedzią, ale nie działa dla mnie. Moja klasa dziedzicząca nie zastępuje atrybutu "Display" klasy bazowej. Jakiś powód, dlaczego? – Kehlan

Jedną z korzyści jest to, że można go używać w wielu widokach i mieć spójny tekst etykiety. Jest również stosowany przez ASP.NET MVC rusztowania wygenerować tekst etykiety i ułatwia generowanie znaczących tekst

[Display(Name = "Wild and Crazy")] 
public string WildAndCrazyProperty { get; set; }

„dziki i szalony” pokazuje się konsekwentnie gdziekolwiek użyć właściwości w aplikacji.

Czasami nie jest to elastyczne, ponieważ możesz chcieć zmienić tekst w jakimś widoku. W takim przypadku będziesz musiał użyć niestandardowego znacznika, tak jak w drugim przykładzie:

Źródło

2012-10-04 21:01:07 codingbiz

W tym przypadku mam tylko jeden pogląd, więc może dlatego nie mogłem dostrzec korzyści. Niezależnie od tej korzyści wydaje się, że można uzyskać większą liczbę wyświetleń, ponownie wykorzystując tę samą właściwość, zanim konsekwencja rekompilacji zostanie przeważona przez tę korzyść. –

Oprócz innych odpowiedzi, istnieje duża korzyść z używania DisplayAttribute, gdy chcesz zlokalizować pola. Możesz wyszukać nazwę w bazie danych lokalizacji za pomocą DisplayAttribute i będzie używać dowolnego tłumaczenia.

Możesz również pozwolić MVC wygenerować szablony za pomocą Html.EditorForModel() i wygeneruje dla Ciebie prawidłową etykietę.

Ostatecznie to zależy od Ciebie. Jednak MVC jest bardzo "zorientowana na modelowanie", dlatego atrybuty danych są stosowane do modeli, dzięki czemu metadane istnieją w jednym miejscu. To nie jest tak, że musisz za dużo pisać.

Źródło

2012-10-04 21:05:56

W moim obecnym przypadku aplikacja jest tylko testowym interfejsem dla usługi WebAPI. Nie jest wymagana żadna lokalizacja; ale widzę korzyści z takiego zachowania. –

@KennethK. - jest wiele rzeczy, które mogą ci teraz nie przynieść korzyści, ale możesz sobie życzyć, że zrobiłeś to później. Używanie architektury trój warstwowej może nie przynieść ci teraz korzyści, ale później ... będziesz walić w głowę. Chodzi o to, użyj go, czy nie ... to twój wybór, ale staraj się nie sugerować, że jest bezużyteczny. –

Jeśli stwierdziłem, że technika jest bezużyteczna, z pewnością nie zamierzałem tego zrobić. Jak już wspomniałem, aplikacja jest po prostu fasadą usługi internetowej. Nie ma szans, aby aplikacja była używana poza tą wydajnością. Ponieważ aplikacja składa się z dokładnie jednego widoku, nie widzę korzyści. Teraz, gdy projektowałem aplikację publiczną z globalną publicznością, tak, to, co opisujesz, ma sens. Wielkość tej konkretnej aplikacji nie wyjaśnia, dlaczego ten atrybut byłby przydatny. –

MVC 4 Adnotacje danych "Display" Atrybut

Odpowiedz

Powiązane problemy