Controlli web di terze parti e accoppiamento stretto

Question

Controlli web di terze parti e accoppiamento stretto

#1 da (4 voti)

2

Disclaimer: I am not against third-party controls because I believe it's for productivity

Ho usato i controlli di Telerik asp.net, in particolare RadGrid perché rende più facile fare CRUD. Hanno controlli fantastici.

Ho pensato che avrei fatto lo stesso per asp.net mvc ma guardando il codice coinvolto mi spaventa.

Ho visto un altro sito (syncfusion.com) che oggi offre gli stessi controlli di mvc e quando guardi l'interfaccia utente, sono accattivanti e quindi sono presenti funzioni / caratteristiche.

Il mio problema con questi controlli simpatici / accattivanti è :

Mi sembra che stia prendendo il controllo che ho sull'HTML che è uno dei vantaggi di asp.net mvc
Non riesco a vedere l'HTML fino a quando non viene eseguita la pagina e visualizzando il codice sorgente
Sento che c'è un accoppiamento tra i dati e il design. Il web designer ha bisogno di imparare il modo di fare Telerik / Syncfusion. Non sarà in grado di utilizzare l'HTML con cui ha familiarità con
Il rasoio sembra un modello che si mescola con HTML e può essere sostituito con un valore codificato a mano per la presentazione e il test che può essere sostituito in seguito

Credo che il seguente codice abbia preso il controllo del mio codice HTML e ne ho un minimo controllo

@section SampleHeading{<span class="sampleName"> Grid/Data Binding/Remote Data</span>}
@section ControlsSection{
@(Html.EJ().Grid<OrdersView>("RemoteBinding")
    .Datasource("http://mvc.syncfusion.com/Services/Northwnd.svc/Orders/")
    .AllowPaging()
    .PageSettings(page => { page.PageSize(9); })
    .Columns(col =>
    {            
        col.Field("CustomerID").HeaderText("Customer ID").Width(90).Add();
        col.Field("EmployeeID").HeaderText("Employee ID").TextAlign(TextAlign.Right).Width(75).Add();
        col.Field("Freight").HeaderText("Freight").TextAlign(TextAlign.Right).Width(75).Format("{0:C}").Add();
        col.Field("ShipCity").HeaderText("Ship City").Width(100).Add();
        col.Field("OrderDate").Format("{0:MM/dd/yyyy}").Width(100).TextAlign(TextAlign.Right).Add();
        col.Field("ShipCountry").HeaderText("Ship Country").Width(100).Add();
    })
  )
}

Si dovrebbe sacrificare la semplicità / il controllo sulla produttività? Quando e perché?

productivity coupling asp.net-mvc separation-of-concerns collaboration

posta tunmise fasipe 30.09.2014 - 16:33

fonte

1 risposta

Leggi altre domande sui tag productivity coupling asp.net-mvc separation-of-concerns collaboration

Scrittura software senza test di unità Come specializzazioni ORM non disgiunte

score 4 · Accepted Answer

Risposta breve: sì.

Anche se vorremmo armeggiare e costruire cose pulite, ci sarà sempre bisogno di spedire la cosa maledetta prima di andare fuori mercato.

Risposta lunga: dipende.

I requisiti e il livello di abilità della squadra possono influenzare la decisione di scegliere l'uno rispetto all'altro, di averne entrambi o di non averne.

Con una scadenza ravvicinata viene focalizzato sulla produttività e poco tempo per armeggiare. Se i requisiti limitano l'uso di controlli di terze parti (principalmente a causa del sovraccarico di markup e risorse generati), il team è responsabile della creazione dei componenti necessari. Se i requisiti non limitano l'utilizzo di controlli di terze parti, la decisione logica sarebbe quella di utilizzare alcuni controlli esistenti, poiché sarà necessario più tempo per crearne di nuovi rispetto a quelli già esistenti.

Le scadenze lente danno un po 'di tempo per sperimentare e la decisione può essere presa per costruire i controlli invece di usare quelli esistenti. L'esperienza può essere acquisita da questo ed è vantaggioso per la squadra nel lungo periodo. Anche così, nella maggior parte dei casi vengono scelte terze parti perché ci sono così tante cose da considerare quando si creano controlli personalizzati e potrebbero essere necessari più tempo rispetto all'intera applicazione che li sta utilizzando.

Nota che i controlli di terze parti sono costruiti tenendo presente la generalità e non si adattano a tutti gli scenari possibili. Da qui la moltitudine di opzioni di configurazione disponibili e la complessità intrinseca (e apparente). E mentre consentono un certo grado di controllo sul markup generato, non è possibile ottenere il 100% a causa del fatto che parte di questo markup è vitale per il modo in cui funzionano.