Großes Anwendungsdesign (WPF/Silverlight)

Question

Wie genau trennen Sie neben dem MVVM- und dem MVC-Muster für die Gesamtstruktur einer WPF-App den Modell/Controller-Aspekt einer App in Unterkomponenten auf? Der Grund, warum ich frage, ist, dass ich kein Problem habe, die Lösung aus der Perspektive der oben erwähnten Muster zu entwickeln, aber wenn es darum geht, das Backend tatsächlich zu schreiben; Ich fühle, dass ich eine Menge davon mache. Ich komme aus der Sicht des Nutzers mit qualitativ hochwertigen Apps, aber meine Design-Ästhetik lässt mich das nicht akzeptieren.

Um zu klären; Viele meiner Geschäftslogik können nicht auf einfache oder sinnvolle Weise in eine Klasse (oder Klassenhierarchie mit allen zugehörigen Schnittstellen) umgestaltet werden, ohne dass die gesamte App geändert werden muss. Ich habe mich jetzt seit eineinhalb Jahren beruflich entwickelt, also könnte es ein Problem der Unerfahrenheit sein; aber ich fühle, dass es immer noch keine Entschuldigung ist. Irgendwelche Hinweise auf diese zugegebenermaßen offene Frage?

Edit: Code-Abfrage (in Silverlight) - Das Folgende ist eine -snippet- von einem mousebuttonup Handler in einer Drag & Drop-Allocation-Anwendung, die Teil einer viel größeren app-

Ich mag es einfach wirklich nicht wie unverblümt die Logik ist, und hasse die Art und Weise, wie alles völlig unberechenbar ist, da alles in Ereignishandler hineingestopft wird.

 //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

Werfen Sie einen Blick auf die Composite Application Guidance aus der Gruppe Patterns and Practices.

Es ist speziell darauf ausgerichtet, einschließlich der Verwendung von MVVM für WPF/Silverlight in Anwendungen im großen Maßstab und wie Geschäftslogik Anliegen behandeln usw.

Answer 2

Sie auch Caliburn überprüfen sollten.