Passa i dati al layout che sono comuni a tutte le pagine

124

Ho un sito web che ha una pagina di layout. Tuttavia questa pagina di layout ha dati che tutti i modelli di pagine devono fornire come titolo della pagina, nome della pagina e la posizione in cui ci troviamo effettivamente per un helper HTML che ho fatto che esegue alcune azioni. Inoltre, ogni pagina ha le proprie proprietà dei modelli di visualizzazione.

Come posso fare questo? Sembra che sia una cattiva idea digitare un layout ma come faccio a passare le informazioni sulle tesi?

asp.net-mvc-4

— Rushino
fonte

10

Per chiunque legga le risposte qui, vedere stackoverflow.com/a/21130867/706346 dove vedrai una soluzione molto più semplice e ordinata rispetto a qualsiasi cosa pubblicata qui.

— Avrohom Yisroel

5

@AvrohomYisroel buon suggerimento. Tuttavia preferisco l'approccio di @Colin Bacon perché è fortemente digitato e non in formato ViewBag. Forse una questione di preferenze. Votato il tuo commento però

— JP Hellemons

per mvc 5 vedi questa risposta: stackoverflow.com/a/46783375/5519026

— Laz Ziya

143

Se ti viene richiesto di passare le stesse proprietà a ciascuna pagina, sarebbe saggio creare un viewmodel di base utilizzato da tutti i tuoi modelli di vista. La tua pagina di layout può quindi prendere questo modello di base.

Se è necessaria una logica dietro questi dati, questa dovrebbe essere inserita in un controller di base utilizzato da tutti i controller.

Ci sono molte cose che potresti fare, l'importante è non ripetere lo stesso codice in più posti.

Modifica: aggiorna dai commenti qui sotto

Ecco un semplice esempio per dimostrare il concetto.

Creare un modello di visualizzazione di base da cui erediteranno tutti i modelli di visualizzazione.

public abstract class ViewModelBase
{
    public string Name { get; set; }
}

public class HomeViewModel : ViewModelBase
{
}

La tua pagina di layout può prenderlo come modello.

@model ViewModelBase
<!DOCTYPE html>
<html>
    <head>
        <meta name="viewport" content="width=device-width" />
        <title>Test</title>
    </head>
    <body>
        <header>
            Hello @Model.Name
        </header>
        <div>
            @this.RenderBody()
        </div>
    </body>
</html>

Infine imposta i dati nel metodo di azione.

public class HomeController
{
    public ActionResult Index()
    {
        return this.View(new HomeViewModel { Name = "Bacon" });
    }
}

— Colin Bacon
fonte

12

Ma i dati vengono utilizzati nel layout. Come posso passare i dati al layout?

— Rushino

2

Perfetto! Ho visto il mio errore. Ho dimenticato di passare il modello alla vista .. che errore zoppo. Grazie!

— Rushino

7

il problema con questo approccio è che a volte non tutte le viste hanno un ViewModel, quindi in questo caso non funzionerà: O /

— Cacho Santa

16

Ma questo non richiederebbe che ogni controller e ogni azione includa il codice {Name = "Bacon"}? E se volessi aggiungere un'altra proprietà a ViewModelBase, dovrei andare su ogni controller e ogni azione e aggiungere il codice per popolare quella proprietà? Hai menzionato "Se è necessaria una logica [...], questa dovrebbe essere inserita in un controller di base [...]". Come funzionerebbe per eliminare questo codice ripetuto in ogni controller e in ogni azione?

— Lee

5

@Lee Se sono dati comuni in tutte le pagine, un controller di base è dove lo metteresti. I tuoi controller ereditano quindi da questo controller di base. es public class HomeController : BaseController. In questo modo il codice comune deve essere scritto solo una volta e può essere applicato a tutti i controller.

— Colin Bacon

73

Ho usato l'helper html RenderAction per il rasoio nel layout.

@{
   Html.RenderAction("Action", "Controller");
 }

Ne avevo bisogno per una stringa semplice. Quindi la mia azione restituisce una stringa e la scrive facilmente in vista. Ma se hai bisogno di dati complessi puoi restituire PartialViewResult e model.

 public PartialViewResult Action()
    {
        var model = someList;
        return PartialView("~/Views/Shared/_maPartialView.cshtml", model);
    }

Devi solo mettere il tuo modello all'inizio della vista parziale '_maPartialView.cshtml' che hai creato

@model List<WhatEverYourObjeIs>

Quindi puoi usare i dati nel modello in quella vista parziale con html.

— Burk
fonte

18

Questa è di gran lunga la migliore risposta!

— gingerbreadboy

@gingerbreadboy ha convenuto che promuove un buon incapsulamento e una separazione delle preoccupazioni.

— A-Dubb

35

Un'altra opzione è creare una classe LayoutModel separata con tutte le proprietà necessarie nel layout, quindi inserire un'istanza di questa classe in ViewBag. Uso il metodo Controller.OnActionExecuting per popolarlo. Quindi, all'inizio del layout è possibile estrarre questo oggetto da ViewBag e continuare ad accedere a questo oggetto fortemente tipizzato.

— DenNukem
fonte

1

Questa in realtà suona come la soluzione meno dolorosa, ci sono degli svantaggi? +1

— formatc

2

Sicuramente la soluzione migliore e non vedo alcun aspetto negativo.

— Wiktor Zychla

7

Non vedo cosa ti sta dando. Se hai una classe con tutte le proprietà necessarie per il layout, perché preoccuparti di aggiungerla a ViewBag solo per doverla lanciare di nuovo? Usa il modello nella vista layout, puoi ancora popolare il modello in OnActionExecuting. Usare ViewBag significa anche perdere la protezione dai tipi nel controller, mai una buona cosa.

— Colin Bacon

3

Ciò che questo mi dà è la possibilità di aggiungere un modello per il layout, senza dover ristrutturare tutti i modelli per ereditare dal singolo modello "super" in tutti i metodi di tutti i controller, in un progetto già esistente. Se stai partendo da zero, puoi invece scegliere di derivare tutti i tuoi modelli dalla radice comune.

— DenNukem

5

@ColinBacon un altro vantaggio di questa opzione è che le tue azioni non devono sempre avere modelli di visualizzazione. Inoltre, direi che gli sviluppatori che hanno bisogno di sapere che devono sempre ereditare i loro modelli di visualizzazione da una base è uno svantaggio.

— Josh Noe,

28

Presumibilmente, il caso d'uso principale per questo è ottenere un modello di base nella vista per tutte (o la maggior parte delle) azioni del controller.

Detto questo, ho usato una combinazione di molte di queste risposte, supporto principale per la risposta di Colin Bacon.

È corretto che questa sia ancora logica del controller perché stiamo popolando un viewmodel per tornare a una vista. Quindi il posto corretto per metterlo è nel controller.

Vogliamo che ciò accada su tutti i controller perché lo usiamo per la pagina di layout. Lo sto usando per le viste parziali che vengono visualizzate nella pagina del layout.

Vogliamo anche ancora il vantaggio aggiuntivo di un ViewModel fortemente tipizzato

Pertanto, ho creato BaseViewModel e BaseController. Tutti i controller ViewModels erediteranno rispettivamente da BaseViewModel e BaseController.

Il codice:

BaseController

public class BaseController : Controller
{
    protected override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        base.OnActionExecuted(filterContext);

        var model = filterContext.Controller.ViewData.Model as BaseViewModel;

        model.AwesomeModelProperty = "Awesome Property Value";
        model.FooterModel = this.getFooterModel();
    }

    protected FooterModel getFooterModel()
    {
        FooterModel model = new FooterModel();
        model.FooterModelProperty = "OMG Becky!!! Another Awesome Property!";
    }
}

Nota l'uso di OnActionExecuted come tratto da questo post SO

HomeController

public class HomeController : BaseController
{
    public ActionResult Index(string id)
    {
        HomeIndexModel model = new HomeIndexModel();

        // populate HomeIndexModel ...

        return View(model);
    }
}

BaseViewModel

public class BaseViewModel
{
    public string AwesomeModelProperty { get; set; }
    public FooterModel FooterModel { get; set; }
}

HomeViewModel

public class HomeIndexModel : BaseViewModel
{

    public string FirstName { get; set; }

    // other awesome properties
}

FooterModel

public class FooterModel
{
    public string FooterModelProperty { get; set; }
}

Layout.cshtml

@model WebSite.Models.BaseViewModel
<!DOCTYPE html>
<html>
<head>
    < ... meta tags and styles and whatnot ... >
</head>
<body>
    <header>
        @{ Html.RenderPartial("_Nav", Model.FooterModel.FooterModelProperty);}
    </header>

    <main>
        <div class="container">
            @RenderBody()
        </div>

        @{ Html.RenderPartial("_AnotherPartial", Model); }
        @{ Html.RenderPartial("_Contact"); }
    </main>

    <footer>
        @{ Html.RenderPartial("_Footer", Model.FooterModel); }
    </footer>

    < ... render scripts ... >

    @RenderSection("scripts", required: false)
</body>
</html>

_Nav.cshtml

@model string
<nav>
    <ul>
        <li>
            <a href="@Model" target="_blank">Mind Blown!</a>
        </li>
    </ul>
</nav>

Si spera che questo aiuti.

— drizzie
fonte

2

Ho usato questo approccio, ma preferisco ereditare da un'interfaccia piuttosto che da una classe base. Così ho fatto: var model = filterContext.Controller.ViewData.Model as IBaseViewModel if (model! = Null) {model.AwesomeModelProperty = "Awesome Property Value"; }

— Tom Gerken

2

ottima risposta, questa l'ho preferita a tutte le altre.

— Jynn

1

Ottima risposta, ma ho una domanda. "E se ho alcune visualizzazioni che non hanno ViewModels ...?"

— Isma Haro

Ho provato questo ma nell'azione Index, OnActionExecuted riempie FooterModel e quindi viene creato un nuovo HomeIndexModel con un FooterModel nullo :(

— SteveCav

1

@drizzie: nel controller di base, model è una variabile locale nel metodo Filter: var model = filterContext.Controller.ViewData.Model come BaseViewModel. Non capisco come MVC capisca che questa variabile locale è la stessa del modello che HomeController sta inviando alla visualizzazione.

— Hooman Bahreini

9

Non devi fare confusione con le azioni o cambiare il modello, usa semplicemente un controller di base ed esegui il cast del controller esistente dal layout viewcontext.

Creare un controller di base con i dati comuni desiderati (titolo / pagina / posizione ecc.) E inizializzazione dell'azione ...

public abstract class _BaseController:Controller {
    public Int32 MyCommonValue { get; private set; }

    protected override void OnActionExecuting(ActionExecutingContext filterContext) {

        MyCommonValue = 12345;

        base.OnActionExecuting(filterContext);
    }
}

Assicurati che ogni controller utilizzi il controller di base ...

public class UserController:_BaseController {...

Trasmetti il controller di base esistente dal contesto della vista nella tua _Layout.cshmlpagina ...

@{
    var myController = (_BaseController)ViewContext.Controller;
}

Ora puoi fare riferimento ai valori nel controller di base dalla pagina del layout.

@myController.MyCommonValue

AGGIORNARE

Puoi anche creare un'estensione di pagina che ti consenta di utilizzare this.

//Allows typed "this.Controller()." in cshtml files
public static class MyPageExtensions {
    public static _BaseController Controller(this WebViewPage page) => Controller<_BaseController>(page);
    public static T Controller<T>(this WebViewPage page) where T : _BaseController => (T)page.ViewContext.Controller;
}

Quindi devi solo ricordarti di usare this.Controller()quando vuoi il controller.

@{
    var myController = this.Controller(); //_BaseController
}

o controller specifico che eredita da _BaseController...

@{
    var myController = this.Controller<MyControllerType>();
}

— Carter Medlin
fonte

Qual è l'equivalente di questo in .net core? Poiché ViewContext.Controller non è presente e c'è qualche cambiamento nella catena di ereditarietà

— Jayanth Thyagarajan

4

se vuoi passare un intero modello vai così nel layout:

@model ViewAsModelBase
<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta charset="utf-8"/>
    <link href="/img/phytech_icon.ico" rel="shortcut icon" type="image/x-icon" />
    <title>@ViewBag.Title</title>
    @RenderSection("styles", required: false)    
    <script type="text/javascript" src="http://code.jquery.com/jquery-1.8.3.min.js"></script>
    @RenderSection("scripts", required: false)
    @RenderSection("head", required: false)
</head>
<body>
    @Html.Action("_Header","Controller", new {model = Model})
    <section id="content">
        @RenderBody()
    </section>      
    @RenderSection("footer", required: false)
</body>
</html>

e aggiungilo nel controller:

public ActionResult _Header(ViewAsModelBase model)

— Villa Yakir
fonte

4

Non credo che nessuna di queste risposte sia sufficientemente flessibile per un'applicazione di livello aziendale di grandi dimensioni. Non sono un fan dell'uso eccessivo di ViewBag, ma in questo caso, per flessibilità, farei un'eccezione. Ecco cosa farei ...

Dovresti avere un controller di base su tutti i tuoi controller. Aggiungi i tuoi dati di layout OnActionExecuting nel tuo controller di base (o OnActionExecuted se vuoi rimandarlo) ...

public class BaseController : Controller
{
    protected override void OnActionExecuting(ActionExecutingContext     
        filterContext)
    {
        ViewBag.LayoutViewModel = MyLayoutViewModel;
    }
}

public class HomeController : BaseController
{
    public ActionResult Index()
    {
        return View(homeModel);
    }
}

Quindi nel tuo _Layout.cshtml estrai il tuo ViewModel dal ViewBag ...

@{
  LayoutViewModel model = (LayoutViewModel)ViewBag.LayoutViewModel;
}

<h1>@model.Title</h1>

O...

<h1>@ViewBag.LayoutViewModel.Title</h1>

Ciò non interferisce con la codifica dei controller della pagina o dei modelli di visualizzazione.

— Jack Sutherland
fonte

Mi piace la tua idea ma se ne hai una MyLayoutViewModelcreata dinamicamente, come posso passare alcuni parametri al OnActionExecutingmetodo?

— Rajmond Burgaj

1

Uh, hai ancora bisogno base.OnActionExecuting(filterContext)del tuo OnActionExecutingmetodo !!!

— ErikE

4

La creazione di una vista di base che rappresenta il modello di visualizzazione Layout è un approccio terribile. Immagina di voler avere un modello che rappresenti la navigazione definita nel layout. Lo faresti CustomersViewModel : LayoutNavigationViewModel? Perché? Perché dovresti passare i dati del modello di navigazione attraverso ogni singolo modello di visualizzazione che hai nella soluzione?

Il modello di visualizzazione Layout dovrebbe essere dedicato da solo e non dovrebbe forzare il resto dei modelli di visualizzazione a dipendere da esso.

Invece, puoi farlo, nel tuo _Layout.cshtmlfile:

@{ var model = DependencyResolver.Current.GetService<MyNamespace.LayoutViewModel>(); }

Ancora più importante, non ne abbiamo bisogno new LayoutViewModel()e otterremo tutte le dipendenze che LayoutViewModelsono state risolte per noi.

per esempio

public class LayoutViewModel
{
    private readonly DataContext dataContext;
    private readonly ApplicationUserManager userManager;

    public LayoutViewModel(DataContext dataContext, ApplicationUserManager userManager)
    {
    }
}

— hyankov
fonte

Dove riempi questo modello? Anche in un BaseController?

— ndberg

Immagino che questa sarebbe una buona idea per un Scopedoggetto modello di layout in ASP..Net Core pure.

— James Wilkins

Non vorrei che la vista andasse a prendere una dipendenza. Questo non è sicuramente "MVC". Service Locator è un anti-pattern .

— Jiveman

Contrariamente alla credenza popolare, Service Locator non è un anti-pattern e in realtà questo non ha nulla a che fare con MVC, stai solo mettendo in giro parole @Jiveman? blog.gauffin.org/2012/09/service-locator-is-not-an-anti-pattern

— hyankov

Il punto principale di Jgauffin in quell'articolo sembra essere che il termine "anti-pattern" non dovrebbe essere applicato a Service Locator, poiché ci possono essere almeno alcuni usi validi di SL. Un punto giusto. Tuttavia, come è evidente in alcuni dei suoi commenti di discussione, suggerisce che mentre SL potrebbe essere un approccio valido quando si creano librerie e framework, non è necessariamente raccomandato quando si creano applicazioni (cosa che considererei la domanda di OP e questa discussione qui come che gira intorno).

— Jiveman

3

Altre risposte hanno coperto praticamente tutto su come passare il modello alla nostra pagina di layout. Ma ho trovato un modo in cui puoi passare le variabili alla tua pagina di layout in modo dinamico senza utilizzare alcun modello o vista parziale nel tuo layout. Diciamo che hai questo modello -

public class SubLocationsViewModel
{
    public string city { get; set; }
    public string state { get; set; }
}

E vuoi ottenere città e stato dinamicamente. Per es

nel tuo index.cshtml puoi mettere queste due variabili in ViewBag

@model  MyProject.Models.ViewModel.SubLocationsViewModel
@{
    ViewBag.City = Model.city;
    ViewBag.State = Model.state;
}

E poi nel tuo layout.cshtml puoi accedere a quelle variabili del viewbag

<div class="text-wrap">
    <div class="heading">@ViewBag.City @ViewBag.State</div>
</div>

— Chirag K
fonte

funziona alla grande, @stun_Gravy c'è un problema nell'usare ViewBag per passare dati come ruolo o livello di accesso utente?

— 3not3

3

C'è un altro modo per gestirlo. Forse non è il modo più pulito da un punto di vista architettonico, ma evita un sacco di dolori legati alle altre risposte. Basta inserire un servizio nel layout Razor e quindi chiamare un metodo che ottiene i dati necessari:

@inject IService myService

Quindi più avanti nella visualizzazione layout:

@if (await myService.GetBoolValue()) {
   // Good to go...
}

Ancora una volta, non pulito in termini di architettura (ovviamente il servizio non dovrebbe essere iniettato direttamente nella vista), ma fa il suo lavoro.

— Andrea
fonte

Non è il modo più pulito? Non sono d'accordo. Penso che sia il più pulito possibile: l'oggetto viene passato dal luogo in cui è stato creato direttamente al luogo in cui si desidera che sia, senza "inquinare" gli altri controller con elementi che non hanno bisogno di vedere. L'utilizzo @injectè la soluzione migliore, secondo me.

— dasblinkenlight il

1

Pensandoci di più forse hai ragione. Il fatto che questo metodo eviti così tanto dolore è un segno che forse è il modo più pulito. Ho lavorato su un'app ASP.NET Core molto grande e sto usando questo modello per cose come la logica breadcrumb di navigazione, i dati di intestazione che si trovano nella maggior parte delle pagine, cose del genere. Ho evitato così tanto dolore facendolo invece in questo modo.

— Andrew

2

Puoi anche utilizzare RenderSection , ti aiuta a inserire i tuoi Modeldati nella _Layoutvista.

È possibile iniettare View Modeldati, Json, Script, CSS, HTMLecc

In questo esempio sto iniettando Jsonda IndexView a LayoutView.

Index.chtml

@section commonLayoutData{

    <script>

        var products = @Html.Raw(Json.Encode(Model.ToList()));

    </script>

    }

_Layout.cshtml

@RenderSection("commonLayoutData", false)

Ciò elimina la necessità di creare una base separata View Model.

La speranza aiuta qualcuno.

— shaijut
fonte

1

Soluzione perfetta quando si solo bisogno di rendere qualcosa di specifico per alcuni punti di vista.

— Kunal

1

quello che ho fatto è molto semplice e funziona

Dichiara la proprietà statica in qualsiasi controller o puoi creare una classe di dati con valori statici se vuoi in questo modo:

public static username = "Admin";
public static UserType = "Administrator";

Questi valori possono essere aggiornati dai controller in base alle operazioni. in seguito potrai utilizzarli nel tuo _Layout

In _layout.cshtml

@project_name.Controllers.HomeController.username
@project_name.Controllers.HomeController.UserType

— E Business
fonte

1

È sempre utile aggiungere qualche spiegazione alla tua risposta, per renderla più chiara e comprensibile. Leggi stackoverflow.com/help/how-to-answer .

— 32cupo

0

Perché nessuno ha suggerito metodi di estensione su ViewData?

Opzione 1

Mi sembra di gran lunga la soluzione meno invadente e più semplice al problema. Nessuna stringa codificata. Nessuna restrizione imposta. Nessuna codifica magica. Nessun codice complesso.

public static class ViewDataExtensions
{
    private const string TitleData = "Title";
    public static void SetTitle<T>(this ViewDataDictionary<T> viewData, string value) => viewData[TitleData] = value;
    public static string GetTitle<T>(this ViewDataDictionary<T> viewData) => (string)viewData[TitleData] ?? "";
}

Imposta i dati nella pagina

ViewData.SetTitle("abc");

Opzione 2

Un'altra opzione, che semplifica la dichiarazione del campo.

public static class ViewDataExtensions
{
    public static ViewDataField<string, V> Title<V>(this ViewDataDictionary<V> viewData) => new ViewDataField<string, V>(viewData, "Title", "");
}

public class ViewDataField<T,V>
{
    private readonly ViewDataDictionary<V> _viewData;
    private readonly string _field;
    private readonly T _defaultValue;

    public ViewDataField(ViewDataDictionary<V> viewData, string field, T defaultValue)
    {
        _viewData = viewData;
        _field = field;
        _defaultValue = defaultValue;
    }

    public T Value {
        get => (T)(_viewData[_field] ?? _defaultValue);
        set => _viewData[_field] = value;
    }
}

Imposta i dati nella pagina. La dichiarazione è più semplice della prima opzione, ma la sintassi di utilizzo è leggermente più lunga.

ViewData.Title().Value = "abc";

Opzione n. 3

Quindi può combinarlo con la restituzione di un singolo oggetto contenente tutti i campi relativi al layout con i loro valori predefiniti.

public static class ViewDataExtensions
{
    private const string LayoutField = "Layout";
    public static LayoutData Layout<T>(this ViewDataDictionary<T> viewData) => 
        (LayoutData)(viewData[LayoutField] ?? (viewData[LayoutField] = new LayoutData()));
}

public class LayoutData
{
    public string Title { get; set; } = "";
}

Imposta i dati nella pagina

var layout = ViewData.Layout();
layout.Title = "abc";

Questa terza opzione ha diversi vantaggi e penso che sia l'opzione migliore nella maggior parte dei casi:

Dichiarazione di campi e valori di default più semplice.
Sintassi di utilizzo più semplice quando si impostano più campi.
Permette di impostare vari tipi di dati nel ViewData (es. Layout, Header, Navigation).
Consente codice e logica aggiuntivi all'interno della classe LayoutData.

PS Non dimenticare di aggiungere lo spazio dei nomi di ViewDataExtensions in _ViewImports.cshtml

— Etienne Charland
fonte

0

È possibile creare un file razor nella cartella App_Code e quindi accedervi dalle pagine di visualizzazione.

Progetto> Repository / IdentityRepository.cs

namespace Infrastructure.Repository
{
    public class IdentityRepository : IIdentityRepository
    {
        private readonly ISystemSettings _systemSettings;
        private readonly ISessionDataManager _sessionDataManager;

        public IdentityRepository(
            ISystemSettings systemSettings
            )
        {
            _systemSettings = systemSettings;
        }

        public string GetCurrentUserName()
        {
            return HttpContext.Current.User.Identity.Name;
        }
    }
}

Progetto> App_Code / IdentityRepositoryViewFunctions.cshtml:

@using System.Web.Mvc
@using Infrastructure.Repository
@functions
{
    public static IIdentityRepository IdentityRepositoryInstance
    {
        get { return DependencyResolver.Current.GetService<IIdentityRepository>(); }
    }

    public static string GetCurrentUserName
    {
        get
        {
            var identityRepo = IdentityRepositoryInstance;
            if (identityRepo != null)
            {
                return identityRepo.GetCurrentUserName();
            }
            return null;
        }
    }
}

Progetto> Views / Shared / _Layout.cshtml (o qualsiasi altro file .cshtml)

<div>
    @IdentityRepositoryViewFunctions.GetCurrentUserName
</div>

— Joel Wiklund
fonte

-1

invece di passare attraverso questo puoi sempre usare un altro approccio che è anche veloce

creare una nuova visualizzazione parziale nella directory condivisa e chiamare la visualizzazione parziale nel layout come

@Html.Partial("MyPartialView")

nella tua vista parziale puoi chiamare il tuo db ed eseguire quello che vuoi fare

@{
    IEnumerable<HOXAT.Models.CourseCategory> categories = new HOXAT.Models.HOXATEntities().CourseCategories;
}

<div>
//do what ever here
</div>

supponendo che tu abbia aggiunto il tuo database Entity Framework

— Asad Ali
fonte

1

Downcasting in quanto non dovrebbe mai essere responsabilità della View ottenere il proprio Modello.

— Oxonhammer,

-1

È incredibile che nessuno l'abbia detto qui. Passare un viewmodel attraverso un controller di base è un casino. Stiamo utilizzando le attestazioni degli utenti per passare informazioni alla pagina di layout (per mostrare i dati utente sulla barra di navigazione, ad esempio). C'è un altro vantaggio. I dati vengono memorizzati tramite cookie, quindi non è necessario recuperare i dati in ogni richiesta tramite parziali. Basta cercare su Google "rivendicazioni di identità net asp".

— makorè
fonte

@ CodeSmith cosa? Sto fornendo una soluzione.

— makore

Colpa mia, pensavo fosse una domanda, ma vedi che è una risposta ora, cancellata.

— CodeSmith

Se questo è un tentativo di rispondere alla domanda, dovrebbe essere chiarito. Il commento è tollerato ma non dovrebbe dominare l'intera risposta; inoltre, i suggerimenti su cosa cercare su Google non costituiscono una risposta valida.

— tripleee

-6

Puoi usare in questo modo:

 @{ 
    ApplicationDbContext db = new ApplicationDbContext();
    IEnumerable<YourModel> bd_recent = db.YourModel.Where(m => m.Pin == true).OrderByDescending(m=>m.ID).Select(m => m);
}
<div class="col-md-12">
    <div class="panel panel-default">
        <div class="panel-body">
            <div class="baner1">
                <h3 class="bb-hred">Recent Posts</h3>
                @foreach(var item in bd_recent)
                {
                    <a href="/BaiDangs/BaiDangChiTiet/@item.ID">@item.Name</a>
                }
            </div>
        </div>
    </div>
</div>

— Ngô Đức Tuấn
fonte

7

La connessione con il database in vista è davvero una pessima idea.

— 1_bug