caliburn a viable silverlight framework for large development?

Question

I have been looking at some frameworks for a very large project like 200+ pages with 50+ tables etc., to develop in silverlight. Is there a best practices or suggestion of framework for developing such a large application? Hopefully it will be multiple technologies that make up the final application and interested to know your opinions on this. One of my friends pointed me to Caliburn as one of best framework. Has anyone used it to develop such a large application?

Answer 1

We use Caliburn on all of our projects (but that's misleading because we the ones who developed it). :-)

Number of tables will have no impact, as Caliburn has nothing to do with data access. Number of "pages" doesn't necessary have an impact either. The use of the term "page" leads me to think that you have a navigation (browser style) UI metaphor in mind. If so, you can still benefit from Calbiurn when using that approach however it is not the natural "Caliburn way".

To sum up, size of the application and complexity doesn't matter. In order to get a better feel of why Caliburn would be useful, I recommend reading the series of posts by Rob Eisenberg, beginning here.

Note that we are encouraging new projects to use Caliburn Micro, instead of the original Caliburn. An additional resource to help might be Rob's video from MIX 10 we he discusses how to roll your own framework (independent of Caliburn).

Answer 2

Hi, we have a slightly smaller project (about 30 pages) built on Caliburn. As I see it, the only complication with more pages would be memory consumption, since caliburn in its out-of-the-box behavior initializes all pages (screens/viewmodels) and keeps them in memory. We have created our custom way of handling this - kind of "lazy screen conductors" that creates viewmodel only when its page is requested and there is also a way to close it (and thus let garbage collector dispose of it). So now it would not matter whether there was 30 or 300 pages in the application. It would eat as much memory as needed for opened pages (supposing a user won't need all 300 pages opened at once).

Btw: I plan to move to Caliburn.Micro so I'll have to move it to this framework. On the other hand, Caliburn.Micro is much cleaner (and I have also much better understanding of it than I had when creating the solution for old Caiburn) so I expect it to be a good idea to refactor the solution.