A thought on LightSwitch modularity: what is LightSwitch, and what is it not… Yet…

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…

And… (This is the important step).  Don’t keep your dream to yourself.  Connect to the LightSwitch team, and tell them your dream.

Advertisements

10 thoughts on “A thought on LightSwitch modularity: what is LightSwitch, and what is it not… Yet…

  1. Very well said Jan!

    I believe that Microsoft has something very special with LightSwitch and we all need to collectively share and push the boundaries of it’s abilities as well express our future functional desires of this product to Microsoft.

    My sense is that MEF is the primary tool for which we can best exploit the inner functionality of LightSwitch and that Microsoft should be the one to lead the development community with clear examples on how to accomplish this. I am very new to LightSwitch but will contribute as much as I can offer. It would be very helpful if we can put together a reference list of good source links as that would help to accelerate this cause.

    You are a true visonary, I love your passion and your ideas and look forward to reading your upcoming articles!

    • Hey John,

      thanks again for your kind words!

      MEF is indeed the prime candidate, it’s a matter of finding the correct extension point really. Due to the lack of documentation and examples, that’s sometimes a struggle, but neither of us is planning on sitting around waiting for it! 🙂

      Keep me posted if you start posting yourself? I would be highly interested to read it, and add a link in my “links” page! 🙂

      Kind regards

      Jan

  2. I think Microsoft has found the fulcrum point for rapid application development with LightSwitch. It’s like the “little engine that could”. Nobody likes slogging away building LOB forms-over-data applications day after day. I need to get that out of the way so I can spend time where it’s needed.

    Microsoft has a very real opportunity with LightSwitch to support departmental domain experts and overworked software developers like myself. If they can seamlessly add technologies like the Workflow Foundation and Prism Modules, they will go a long way toward providing programmers like myself the tools I need.

    Give me a better shovel to dig a deeper foxhole, not a jet powered bulldozer missing the manual.

  3. I dream to be able to create separate LS applications that could be merged at runtime through a LS root application into a composite LOB application. It’s a pity they haven’t done it in the first version although they extensively use MEF to discover different application parts. Adding module support will break the limits for creating real LOB applications and I think it’s not so much work compared to the rest of that they have already done. I can’t wait for the moment when something like this will be added and I’m looking for a solution allowing me to create composable LS application before the next LS version (unfortunatelly I’m almost convinced that this can’t be done under the existing restirctions in the current LS version).

  4. Lightswitch has the potential to save thousands of hours of dev time. We have selected it as a platform for a custom solution that is integrated with SAP B1 data and the results have been amazing. I have spent many years working on MVVM based WPF applications and the time that has been wasted on simple CRUD operations is simply ludicrous. The key to adopting Lightswitch is to take off your nerd cap and start thinking like a business person, “how can I develop a stable, reliable application with minimal wasted effort on repetitive, boilerplate tasks in development” Use your hours on good software structure, process analysis and solution design not coding to suit text box frameworks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s