views:

112

answers:

2

I'm having a little trouble as I decide how to structure my projects. This question is slightly subjective, but I'm having trouble conceptually.

If I create a wpf blend project (sketchflow right now), it creates two projects, "Project" and "ProjectScreens". Is this the best layout to use?

The issue is, I have classes and code (networking, file i/o, etc.) that I need to reference within the screens (i.e. they click a button, it creates a network connection), and the core code needs to reference the screens. This creates a circular dependency.

I've tried merging them all as a single project, which works, but it stops becoming a sketchflow project at that point.

I guess the big thing, what's the best way to structure this with my core code and my sketchflow prototype?

+3  A: 

Check out the Model-View-ViewModel design pattern. You'll find it fits well for WPF (and Sketchflow) projects because it keeps your business logic independent of your UI and supports the binding-oriented development model of WPF.

Jerry Bullard
Thanks for the reference. It's an interesting design pattern, and exactly what I was looking for.
mattjf
A: 

The SketchFlow project is separated into 2 assemblies so that you can do all of your work in the screens assembly, and then later re-use what is in the screens assembly elsewhere if you want.

The main project is a very simple wrapper that enables the use of the SketchFlow runtime player.

Chuck Hays