Telerik controlli con ASP.NET MVC: Questo viola il modello MVC?

Question

1. L'uso dello MVC attivato controlli Telerik con ASP.NET MVC violare il modello MVC?

2. E se no, che tipo di prestazioni HIT (rispetto a caratteristiche e velocità di sviluppo) ci sarà con l'utilizzo Telerik controlli sui manualmente codifica il codice HTML?

Answer 1

Dato che io sono la persona che ha costruito quella demo credo di poter condividere la mia opinione come bene. Questa applicazione di esempio non viola i principi MVC secondo me. RadControls non si basano su ViewState o postback nelle applicazioni MVC (è possibile controllare l'output generato per vedere di persona - non __doPostBack o __VIEWSTATE). Infatti è necessario scrivere del codice di impegnare la griglia o popolare il menù - ma ancora il codice è in vista (ASPX) ed è interamente in relazione con la presentazione (di nuovo questo è solo la mia opinione quindi potrei sbagliarmi)

Vorrei anche ricordare che ci sono alcune limitazioni infatti - alcune delle funzionalità integrate (che si basano su postback) non funzionano in MVC. Tuttavia lavorerà su risolverli. Sentitevi liberi di aprire una richiesta di assistenza o di thread del forum se avete tutte le domande particolari per quanto riguarda RadControls e ASP.NET MVC.

Answer 2

Per la seconda domanda, riguardo alle prestazioni di successo contro codifica manuale, penso che dipende dal controllo che si sta utilizzando. Ad esempio, se si utilizza uno qualsiasi dei controlli di navigazione Telerik in MVC- come Menu, TabStrip, o PanelBar- potrai risparmiare una tonnellata di codifica manuale (dal menu / tabstrip / etc. Richiede un sacco di lato client il codice per fornire le caratteristiche interattive (come drop down opzioni) e un sacco di complessi CSS). Così, i RadControls in MVC contribuirà a ripristinare il - produttività -. Si è abituati a quando si costruisce ricche applicazioni ASPNET

Per controlli complessi di più, come la griglia, che dipendono molto su postback, si sta beneficiando principalmente dal styling fornito. Per adattare il modello MVC, controlli come la griglia richiedono un po 'di "custom" di codifica di "convertire" gli eventi di postback a URL azioni, quindi non si possono risparmiare un sacco di codice rispetto a un modello di griglia MVC. È -will- risparmiare un sacco di tempo su stile, però, e la differenza di prestazioni dovrebbe essere negligble.

La speranza che aiuta.

-Todd

Answer 3

Sono abbastanza sicuro che questi si basano sul modello di postback in WebForms e non sarebbero compatibili con vista MVC. Si potrebbe probabilmente trovare un modo per loro di lavorare, ma non sarebbe in linea con i principi MVC. È possibile combinare / partita WebForms con MVC Vista nello stesso sito web, se necessario, ma io non lo consiglio.

Che cosa si perde utilizzando i controlli Telerik sono la maggior parte dei benefici della MVC: chiara separazione degli interessi, una maggiore verificabilità, più snella HTML, un'architettura pulita. Non mi sorprenderebbe scoprire che alla fine Telerik esce con controlli per MVC. Per il momento, mi piacerebbe guardare in puro JavaScript per implementazioni lato client o ViewUserControls codificati a mano se avete bisogno di riutilizzare alcuni componenti comuni.

Answer 4

Personalmente, non vorrei usare i controlli Telerik attuali con MVC. Credo che lavorano in alcune situazioni ( http: // telerikwatch.com/2009/01/telerik-mvc-demo-app-now-available.html ), ma penso che siano abbastanza viewState / postback centric. Sapendo Telerik, che uscirà con una versione compatibile MVC, ma sembra che hanno un sacco di lavoro davanti a loro ...

Answer 5

Mi rendo conto che è una vecchia questione, ma Telerik di controlli ASP.NET MVC sono controlli semplicemente, come datepickers, griglie, panelbars, tabstrips. Questi non sono nella rivale della MVC quadro . Lavorano in combinazione di esso. La tua domanda mi dice che non lo fai, o almeno ha non, capire che cosa è veramente MVC.

Per il bene degli altri che possono essere confusi, così, MVC sta per Model-View-Controller . C'è un Modello , che rappresenta gli oggetti che si utilizza per la conservazione o il recupero di valori, un Visualizza , che visualizza i valori degli oggetti e può essere utilizzato per impostare loro attraverso l'uso di < em> controlli , come ad esempio datepickers di Telerik, griglie, e simili, e la controller , che ospita le funzioni che rendono il punto di vista e interagisce con gli elementi del modello. I comandi che si utilizzano per l'aggiornamento del modello deve essere in grado di interagire con quel modello di essere MVC-compliant. Se non lo facessero, non potevano essere pubblicizzati come controlli MVC, in primo luogo, quindi sì, i loro controlli con cui lavorare, e non fanno "viola", il framework MVC.

Ecco un tale utilizzo di un controllo datepicker, in combinazione con un modello:

VISTA:

@model MyViewModel

<%= Html.Kendo().DateTimePickerFor(model => model.ExpirationDate)
    .Name("datetimepicker")
    .Value(model.ExpirationDate)        
%>

ViewModel: (o modello)

public MyViewModel() {
    public DateTime ExpirationDate { get; set; }
}

CONTROLLER:

public ActionResult Index(int id)
{
    var data = dataContext.SomeTable.Where(e => e.ID == id).FirstOrDefault();
    // return View(data); // this would allow you to use @model SomeTable 
    // in your view, and not require a ViewModel, but returns the whole 
    // record for the given ID

    // ViewModels allow you flexibility in what you return
    MyViewModel mvm = new MyViewModel();
    mvm.ExpirationDate = data.ExpirationDate;
    return View(mvm);
}

Per la codifica utilizzando demo di Telerik, si tratta di un sacco di copia / incolla e vari piccoli modifiche per il modello ed i dati si stanno inserendo specifici (come indicato sopra). C'è anche molto meno codice, perché i controlli hanno la maggior parte tutto built-in, in modo del tempo di produzione naturalmente viene tagliato fino in fondo, le cose come il filtraggio, il paging, l'ordinamento in griglie è già lì - si accende solo con l'aggiunta per esempio, Filterable(), per il filtraggio. Invece di dover creare, per esempio, i singoli DataColumns e aggiungerli a un DataTable, quindi associare che a una griglia, poi preoccuparsi di singoli OnDataBound eventi (che si potrebbe ancora fare, ma bisogno di meno di), si crea un'istanza di una griglia, aggiungere le colonne, impostare le funzioni del controller per la creazione, la lettura, l'aggiornamento e l'eliminazione di elementi, e impostare le proprietà sulla griglia, e si è fatto:

<%: Html.Kendo().Grid<Models.ViewModels.MyViewModel>()
    .Name("grid")
    .Columns(columns =>
    {
        columns.Bound(c => c.ExpirationDate).Format("MM/DD/YYYY");
    })
    .HtmlAttributes(new { style = "height: 380px;" })
    .Scrollable()
    .Sortable()
    .Filterable()
    .Pageable(pageable => pageable
        .Refresh(true)
        .PageSizes(true)
        .ButtonCount(5))
    .DataSource(dataSource => dataSource
        .Ajax()
        .Read(read => read.Action("Customers_Read", "Grid"))
        .Create(create => create.Action("Customers_Create", "Grid"))
        .Update(update=> update.Action("Customers_Update", "Grid"))
        .Delete(delete => create.Action("Customers_Delete", "Grid"))
    )
 %>

Il "leggere" è semplice come prendere le prime 2 righe nella public ActionResult Index() sopra e mettendoli in una funzione che restituisce public Customers_Read([DataSourceRequest] DataSourceRequest request) {} data come .ToDataSourceResult(). L'aggiornamento è simile a quello degli ultimi 3 linee in quella funzione, dal momento che si crea un'istanza del modello, copiare i valori dal modello che viene passato dalla rete, poi fare qualcosa di simile dataContext.SaveChanges() per salvare. Una volta salvata, la griglia fa automaticamente un'altra lettura, ti vedere le ultime valori. Non c'è bisogno di niente altro per l'esecuzione su postback per associare nuovamente i dati, quindi non più codice da scrivere.

Basta guardare gli esempi di codice qui per dare una migliore idea: http: //demos.telerik. com / aspnet-MVC /