Progettazione di applicazioni di grandi dimensioni (WPF/Silverlight)

Question

Oltre al MVVM e ai modelli MVC per la struttura generale di un'app WPF, in che modo si suddivide esattamente l'aspetto del modello/controllore di un'app in componenti secondari? Il motivo per cui lo chiedo è che non ho alcun problema a progettare la soluzione dal punto di vista degli schemi sopra menzionati, ma quando si tratta di scrivere effettivamente il backend; Sento che me ne sto scottando un sacco. Finisco con app di alta qualità dal punto di vista dell'utente, ma le mie tecniche di progettazione non mi consentono di accettarlo.

Per chiarire; molte delle mie logiche di business non possono essere refactored in una classe (o gerarchia di classi, con tutte le interfacce associate) in qualsiasi modo facile o significativo senza dover modificare l'intera app. Sto sviluppando professionalmente da un anno e mezzo, quindi potrebbe essere un problema di inesperienza; ma sento che non è ancora una scusa. Qualche suggerimento su questa domanda dichiaratamente aperta?

Edit: Richiesta codice (in Silverlight) - Il seguente è un -snippet- da un gestore mousebuttonup in un'applicazione di assegnazione drag-drop che fa parte di un più vasto app-

io sinceramente non piace quanto è spigolosa la logica, e odia il modo in cui tutto è completamente inattaccabile, dal momento che tutto si sta insinuando nei gestori di eventi.

 //determine if there is a previously existing allocated sale corresponding to this purchase's ID 

       SaleWS allocSaleExisting = colltoaddsale.FirstOrDefault(s => (s.p_TRADEID == allocPurch.TRADEID)); 


       if (allocSaleExisting != null && allocSale.TRADEID == allocSaleExisting.TRADEID) 
       { 
        PurchaseWS allocPurchExisting = colltoadd.First(p => p.TRADEID == allocPurch.TRADEID); 

        //allocPurchExisting.AMOUNT += allocPurch.AMOUNT; 
        allocSaleExisting.AMOUNT += allocSale.AMOUNT; 


        allocPurchExisting.AMOUNT += allocSale.AMOUNT; 
        allocPurch.AMOUNT -= allocSale.AMOUNT; 


        colltoaddsale.Remove(allocSale); 


        //colltoadd.Remove(allocPurch); 

       } 

       else 
       { 


        //Create new "split" item in the data source for the source table 
        PurchaseWS splitAllocPurch = new PurchaseWS { COMMODITY = allocPurch.COMMODITY, CONTRACTNUMBER = allocPurch.CONTRACTNUMBER, AMOUNT = allocPurch.AMOUNT - allocSale.AMOUNT, FORM = allocPurch.FORM, GRADE = allocPurch.GRADE, LOCATION = allocPurch.LOCATION, SHIP_DATE = allocPurch.SHIP_DATE, TRADEID = allocPurch.TRADEID, UNITS = allocPurch.UNITS }; 

        //update the source table's selecteditem datacontext with the target allocation id 

        allocPurch.s_TRADEID = allocSale.TRADEID; 

        allocSale.p_TRADEID = allocPurch.TRADEID; 

        allocPurch.AMOUNT = allocSale.AMOUNT; 




        colltoadd.Insert(colltoadd.IndexOf(allocPurch) + 1, splitAllocPurch); 







       } 


      } 

Answer 1

Dai uno sguardo allo Composite Application Guidance dal gruppo Patterns and Practices.

E 'orientato in particolare nei confronti di questo, anche utilizzando MVVM per WPF/Silverlight in applicazioni su larga scala, e come gestire le preoccupazioni logica di business, ecc

Answer 2

Si dovrebbe anche controllare Caliburn.