Since I've been experimenting with Silverlight V2.0 Beta1 (business logic in V1.0 was mostly JavaScript code, so mostly the same structure as regular web development), I've just played around by testing snippets of code in "test" projects. Now that I try to build more serious projects, I struggle on how structuring my project. I know, it might sounds stupid but Silverlight is not  Winform nor ASP.NET...or a little of both.

As much as people like to talk about the separation between design and business logic, I think it's a personal thing (as in "you", "your team" or "your company"). When the language/platform allows the developer to write "design" part in the business logic side and some business logic in the design side, it always ends up with "spaghetti" code. I remember classic ASP when we were mixing the client side JavaScript and the server side JavaScript code between HTML tags (supposedly the design part)... and when ASP.NET arrived it was supposed to be "the" answer for "spaghetti" code... I think I've seen worst in ASP.NET then ASP... design part done by spitting HTML strings from server controls. Even if it's the core of ASP.NET (hide the HTML spitting from the developers), there are a better ways of doing this (but anyway that's old technology, LOL).

With Silverlight, there is no "server side" code... but there is still a layer separation: user interface (UI) vs. user experience (UX).  So, we are faced again with the same interrogations... for example, should I write my "animation" in directly in XAML or create it dynamically from C#?  I'll find my way through experimentations...

I read Jose Fajardo blog frequently and two weeks ago he wrote about his preferred way of structuring his Silverlight projects. I really like it. I'll "borrow" his idea and start my new project with this structure. We'll see how much I'll keep the original form.