Quali sono gli errori / gli errori più comuni di Silverlight che gli sviluppatori dovrebbero evitare? [chiuso]

7

Quali sono alcuni errori / insidie comuni, specifici dello sviluppo di Silverlight, che gli sviluppatori dovrebbero evitare?

PS: Per favore, se non hai esperienza pratica con Silverlight e vuoi semplicemente dire che le persone non dovrebbero semplicemente usarlo, astenetevi dal farlo.

Grazie per il tuo tempo e considerazione.

Ecco una raccolta di input dagli utenti sia su StackOverflow che su programmers.stackexchange.com a questa domanda:

  • Pensando che sia lo stesso di WPF
  • Non si utilizza il modello di progettazione MVVM
  • Non sapendo che non supporta connessioni ADO.Net
  • Non sapendo che supporta solo basicHttpBinding (non è consentito wsHttpBinding)
  • Non sapendo che i legami RelativeSource non supportano AncestorType
  • Dimenticando di configurare i tipi MIME di IIS
  • Pensando che Silverlight funzioni allo stesso modo di WPF
  • Limite di 5 MB sui file XAP e necessità di soluzioni di terze parti per ovviare a ciò
  • Non astrarre le chiamate del livello di servizio.

    Abstracting out the service layer calls so that the silverlight pages load in the designer (either Visual Studio or Expression Blend) without the presence of the service helps out. Especially if the UI is being designed in Expression Blend. Some dummy data can be returned without calling the service and the UI designers still get a feel for the look and feel of the application with data.

  • Non si usa MVVM

    You can program Silverlight like a winforms app but you are in for a world of grief. The whole platform was designed to use MVVM and if you don't work with that you are going to be swimming upstream the whole way.

  • Rete: ci sono dei limiti sui socket, ad es. no UDP, solo il modello asincrono

  • Networking: due (3.0) diversi stack HTTP, uno browser e uno client - ognuno ha i suoi propri capricci (molte applicazioni finiscono per utilizzare entrambi);

  • Sicurezza: alcune API sono contrassegnate come [SecurityCritical] e non ti sarà consentito utilizzarle, anche se verranno compilate correttamente, in fase di esecuzione (ad esempio, ma quel codice ha ho lavorato per anni nella mia altra applicazione)

  • Sicurezza: politiche di sicurezza su HTTP [S] e socket (ma funziona così bene sul tuo computer)
  • ditran.net/silverlight-common-errors
  • Utilizzare MVVM ma non capirlo veramente

    blindly obeying its principles as if they were the 10 commandments, some people really make things hard for themselves I bet most don't have any separate UI design team nor are using Unit tests, so the benefits of MVVM would be minimal

  •   
  • Non cogliere la natura asincrona di Silverlight.
  •   
  • Uso eccessivo degli UserControls quando dovrebbero utilizzare un controllo basato su modelli
  •   

Grazie per il contributo costruttivo alle seguenti persone:   Rachel, maple_shaft, Jesse C. Slicer, ChrisF, Jon Raynor, poupou, RKitty, DShah, AnthonyWJones

    
posta Dmitry 31.08.2011 - 18:35
fonte

5 risposte

7

I principali problemi che ho riscontrato durante la creazione di un'app Silverlight sono stati:

  • Pensando che sia lo stesso di WPF
  • Non si utilizza il modello di progettazione MVVM
  • Non sapendo che non supporta connessioni ADO.Net
  • Non sapendo che supporta solo basicHttpBinding (nessun wsHttpBinding consentito)
  • Non sapendo che RelativeSource binding non supporta AncestorType
  • Dimenticando che i client avessero bisogno di installare il framework Silverlight per eseguirlo
  • Dimenticando di configurare i tipi MIME di IIS

Sono sicuro che ci sono altri problemi, ma li dimentico. Di solito faccio lo sviluppo WPF e ho fatto solo una manciata di app Silverlight. Il più grande problema che ho avuto è stato pensare che Silverlight fosse lo stesso di WPF ... non lo è. Ci sono molte cose che puoi fare in WPF che non puoi fare in Silverlight.

    
risposta data 31.08.2011 - 18:55
fonte
1

Non usare MVVM è il più grande errore che ho visto. Puoi programmare Silverlight come un'app di Winforms ma ti trovi in un mondo di dolore. L'intera piattaforma è stata progettata per utilizzare MVVM e, se non lavori con questo, dovrai nuotare controcorrente per tutto il percorso.

    
risposta data 31.08.2011 - 22:06
fonte
1

Networking:

  • ci sono dei limiti sui socket, ad es. no UDP, solo il modello asincrono - la successiva è una buona cosa IMO;

  • due (3.0) diversi stack HTTP, uno browser e uno client - ognuno ha i suoi propri capricci (molte applicazioni finiscono usando entrambi);

Ci sono parecchie considerazioni sulla sicurezza. Le maggiori insidie (funziona in alcuni casi, non nella mia app) sono:

  • alcune API sono contrassegnate come [SecurityCritical] e non ti sarà consentito utilizzarle, anche se verranno compilate correttamente, in fase di esecuzione (ad esempio, ma il codice funziona da anni nella mia altra applicazione) ;

  • criteri di sicurezza su HTTP [S] e socket (ma funziona così bene sul tuo computer);

risposta data 01.09.2011 - 01:35
fonte
1

La maggior parte delle app Silverlight utilizza servizi per ottenere dati. Aggiungerei l'astrazione delle chiamate del livello di servizio in modo che le pagine silverlight vengano caricate nella finestra di progettazione (Visual Studio o Expression Blend) senza la presenza del servizio. Soprattutto se l'interfaccia utente è stata progettata in Expression Blend. Alcuni dati fittizi possono essere restituiti senza chiamare il servizio e i progettisti dell'interfaccia utente hanno ancora un'idea del look and feel dell'applicazione con i dati.

    
risposta data 31.08.2011 - 23:17
fonte
1

Non essere in grado di sfruttare le DLL della libreria di classi esistenti.

Le applicazioni Silverlight sul lato client devono essere collegate alle librerie di classi Silverlight.

Questo potrebbe obbligarti a mantenere la logica aziendale sul server (che funziona bene con le normali librerie di classi .NET) - che è una buona cosa!

    
risposta data 01.09.2011 - 21:52
fonte

Leggi altre domande sui tag