Earlier today, a friendly fellow named John Kears from Avanade left me a message…
One other thing that concerns me a little with LightSwitch, is that I got very use to building Modules within PRISM so that I could offer and segment Business functionality in Modules, that were discovered at runtime. This allows me to position Module development to separate teams to work in isolation and then inject these Modules into the UI and application at runtime. To me at least, it becomes a much easy thing to manage especially when creating a large set of LOB functionality.
Perhaps its that lack of documentation I seek that gives me this sense of uneasiness that LightSwitch doesn’t have a good Enterprise development approach or perhaps its because I am still new to it all. I’d be interested to learn what others think about that and some of the techniques that we can employee to organize LightSwitch projects to be more manageable in that sense.
I believe that had Microsoft leveraged the MEF Catalog and PRISM Module type approach, where you could create separate loosely coupled Modules through Interface definition, that this would provide a much better development approach.
Like I said, it’s just a concern, likely one that is less warranted than its worth discussing.
Regardless, I love LightSwitch and I see this saving our organization hundreds of thousands of dollars over the next few years, if not millions. I know to some of you out there, this may seem like a ridiculous statement, but if you have ever been responsible for 100K business users running your applications, strewn across the globe, who have and want flexible LOB applications with as little a cost as possible, I can assure you, LightSwitch has what it takes to provide that level of LOB and user base support. I know that the technology does work because we have built a ton of SilverLight/WCF RIA service solutions and they simply are far easier to build, deploy and maintain. LightSwitch is a quantum leap forward in the LOB space. It’s definitely got the legs and I can’t wait to dig in deeper!
I must admit that the idea of having multiple LightSwitch modules come together at runtime, has been on my mind as well since day one. Especially because, just like John, I spend most of my day working on a large enterprise application, that uses different functional modules, combined at runtime, backed by a WCF service oriented architecture.
LightSwitch however, does not support the idea of functional modules in any way ( well, not natively…), and to be honest, this should not be a very surprising fact. Have a look at any official “what is LightSwitch” article on the web, and it’s quite obvious what the goal of LightSwitch is. LightSwitch is the easiest way to build a specific in-house application, to address a specific company problem. Considering that scope, the LightSwitch team met that goal. The team did an amazing job. LightSwitch is amazing. Perhaps… Too amazing.
Way too amazing to limit the scope to in-house applications.
Because here’s the problem: developers are artists. They are creators. Dreamers. And upon seeing LightSwitch, they dream about how much better the enterprise application they have spent years working on, would have been, if LightSwitch were released when the enterprise application was started.
And they are right.
If you would ask John Kearse, Eric Miller, me, or any other professional with the slightest experience in this area, LightSwitch has what it takes to build large, modular, enterprise applications. The anatomy of a LightSwitch application is just brilliant. Silverlight 5 is right around the corner, offering full trust applications to run from a browser, and support for Windows platform invokes. Prism already has awesome support for modular applications. Hints of native XAML in windows 8…
So join me in dreaming, not about what LightSwitch is missing, but about what’s not in LightSwitch yet…