My Application has the following structure:
- myproject (primary Silverlight project)
- myproject.Web (website for the app)
- myproject.Controls (Class library so I could do some inheritance with controls)
- myproject.Classes (Classes representing the data the controls bind to)
It seemed like a good idea having these split into projects with their own sub-namespaces, but I’m running into a lot of coupling issues and that is leading to circular dependency namespace problems.
From what little iOS development I have done, it feels kind of like I am trying to roll my own MVC solution here. What is the recommended way of going about having controls (essentially forms) backed by data in a Silverlight app?
I suggest doing that split within the primary Silverlight application itself (a single project with multiple folders). Unless you know right now that you will have to reuse the code within the classes and controls namespaces within different Silverlight applications, I would avoid it. Silverlight is UI, anything you will want to reuse should be in the ASP.NET part of the project (logic, db access, business rules, etc).
If you take this approach, your UI won’t become an albatross around your neck.
Keep your Silverlight applications thin, fast and pretty – I promise you won’t regret it.
EDIT: The downvote made me realize I was unclear (clearer, more concise version below):
Don’t split your solutions into projects based on namespaces – it leads to needless complication. Use namespaces within projects to organize code. Keep project counts to a minimum, and only split when there is a compelling need.
Good Luck!