Zalecana struktura projektu WPF?

Jestem zwolenniczką dobrych struktur Visual Studio Solution i Project.Zalecana struktura projektu WPF?

Mam zamiar rozpocząć dokumentację WPF z koncepcją koncepcji.

Czy ktoś może polecić niektóre konstrukcje projektów WPF, z których się korzystały i które okazały się skuteczne?

Tutaj http://drwpf.com/blog/2007/10/01/58/

Mają jedno zalecenie, które lubię:

Root 
    - Pages 
    - Controls 
    - Resources 
    App.xaml

Gdzie Pages, kontroluje i zasoby są foldery.

Czy ktoś stwierdził, że pewne struktury działają dobrze/nie działają dobrze?

Poza tym wolałbym nie wdawać się w dyskusję "Model View Presenter", jeśli jest to w porządku z wami.

Źródło

2010-08-06 Lee Englestone

Poważnie, dlaczego potrzebujesz czegoś w tym celu? Możesz przeciągać/upuszczać rzeczy później, jeśli zajdzie taka potrzeba, a obsługa refaktoryzacji w VS (szczególnie 2010) jest raczej dobra. – slugster

Nie masz czasu na początku, aby zaplanować rzeczy przed rozpoczęciem? Jeśli nie zdołasz przygotować się do porażki. Oczywiście, możesz później coś zmienić, ale to nie jest dobry argument za tym, że nie poświęcasz czasu na początku i czy to jest planowanie? –

Chodzi mi o to, że podany przykład jest w porządku, dlaczego ludzie muszą go krytykować? Z całą pewnością planuj z wyprzedzeniem, ale pamiętaj też, że na początku projektu rzeczy będą nieco płynne, a ty zmienisz lokalizacje i przestrzenie nazw rzeczy. Kategoryzuj rzeczy w sposób, który ma sens ** dla Ciebie i Twojego zespołu. Po tygodniu lub dwóch znajdziesz rzeczy, które się uspokoją i nie będziesz przesuwać rzeczy tak bardzo, jeśli w ogóle. Organizowanie * projektu * to nic wielkiego - zorganizowanie * rozwiązania * z wyprzedzeniem ma większy zwrot z inwestycji za czas planowania. – slugster

Mam zwykle następujące katalogi: Konwertery, modele, zasoby, ViewModels i widoki.

Widziałem również rozwiązanie, w którym widok i ViewModels zostały wydzielone do oddzielnych projektów (patrz BubbleBurst na CodePlex)

Źródło

2010-08-06 11:40:59 alimbada

Dzięki za zdobycie piłki toczącej alimbada –

zgadzam się z alimbada. Stworzyliśmy także różne projekty dla modeli View i View. Ułatwia konserwację w przypadku dużych projektów. Katalogi mieliśmy były -

- ViewsRoot 
    + Base 
    + Controls 
    + Documentation 
    + Forms(Windows) 
    + Reports 
    + Resources 
    + Themes 
    + Utilities 
    App.xaml 

- ViewModelsRoot 
    + Collection 
    + Commands 
    + Converters 
    + Resources 
    + TemplateSelectors 
    + ViewModels 
    + Views (Interfaces for views) 
    Constants.cs 
    Utility.cs

Wierzę również w planowaniu struktury wcześniej, to sprawia, że jest łatwy dla wszystkich programistów, aby przyzwyczaić się do niego i wykonaj to samo. Wykonanie tego później powoduje zamieszanie i jest bolesne w przypadku, gdy musisz tworzyć projekty indywidualne. To mój pogląd i jestem otwarty na poznanie innych lepszych pomysłów na ten temat.

Źródło

2010-08-06 12:42:09 akjoshi

Podoba mi się to. Gdzie umieściłbyś Załączone Właściwości/Zachowanie w tym schemacie? Rozdzielam to na osobny folder, który nazywam Zachowaniem. – Berryl

Mam również "podstawowy" projekt elementów wpf, które są wielokrotnego użytku w wielu projektach.Rzeczy, takie jak stałe, narzędzia, sterowanie i zachowanie (które również prawdopodobnie mają odpowiedniki w konkretnych projektach). – Berryl

Miałem ochotę zmienić nazwę Zasoby na zasoby, tylko dlatego, że zasób jest tak obciążoną koncepcją, zwłaszcza jeśli zajmujesz się lokalizacją. Pozdrawiam – Berryl

Odpowiedz

Powiązane problemy