locked
Do we need to use Prism/MEF with LS? RRS feed

  • Question

  • a) For those of us who plan to build app using LS, do we need to get involve with Prism, MEF, MVVM while we are building app within the framework of LS?

    b) Secondly, when it comes to extending LS, does this notion come to play at all or this has already been taken care of within LS framework?

    Thanks!
    ..Ben


    WPF/Silverlight Insider
    Friday, November 12, 2010 4:15 AM

Answers

  • There are two ways to read your question.

    The first asks if users of LightSwitch need to use or even be aware of MVVM, MEF, PRISM and the like either to use the product or especially for extensibility. The answer is definitely no on MEF: V1 extensibility handles all MEF goo for you. Of course the answer is yes for MVVM if a person does their own Silverlight, since MVVM is the Silverlight model. The answer is no for PRISM, as there are no hook points that expect or require PRISM to be a part of the mix. (Neither does it block use of PRISM though.)

    The second read of your question asks if clever folks who want to make LightSwitch do things it isn't built to do directly might find a way to achieve their goals with creative use of MVVM, MEF, PRISM and the like. The answer to that is perhaps--it depends upon what you want to do.

    The particular scenario you mentioned was modularity. The black and white answer is that there will not be hook points for the kind of modularity you want in V1. The best way to do that is probably the container approach you and Mike were discussing, though of course that has limits as you've pointed out. Some of the bugs we're fixing in B1 let you solve some of the problems (e.g. in auth) that prevent a clean container story, but I want to emphasize that they're bug fixes, not features.

    Steve

    P.S. I should add that LightSwitch locks down its use of MEF for the most part.

    • Marked as answer by Ben Hayat Sunday, November 14, 2010 10:15 PM
    Sunday, November 14, 2010 10:08 PM
    Moderator
  • What is the error you're seeing? Provide as much detail as you can so we can help diagnose the issue.

    LightSwitch doesn't actively block use of MEF, but the default configuration may not be what you expect because LS uses MEF extensively itself.

    Steve

     

    Tuesday, November 16, 2010 5:51 PM
    Moderator

All replies

  • I don't fully understand the question.  You've been using LS thus far, and have not needed to think about MEF, MVVM, etc, right?

    Our intention is that MEF is our implementation detail, and not something LS customers think about.  Technically we could be exposing our MEF usage and widely talking about it as a 3rd party extensibility point, but that's not something we're doing and I don't think that will be part of the messaging for V1.

    Is this close to what you were asking about?

    Friday, November 12, 2010 3:47 PM
  • Technically we could be exposing our MEF usage and widely talking about it as a 3rd party extensibility point, but that's not something we're doing and I don't think that will be part of the messaging for V1.

    Is this close to what you were asking about?


    Matt, my original post was much longer and was centered exactly around the point you brought up and I then cut it off and made it more of a general question to cover more area.

    Yes, you're right and I haven't had a need to use MEF or Prism while coding in LS, but now that you nailed it on my point, two questions come up:

    a) What about the extensibility cases where there are needs to build extensions. Are we going to have access to the MEF methodology that is used in LS?

    b) A question that was raised before and we never got a black & white answer to it. What about building apps that need to be modularized and to break it up to smaller modules for faster loading and be under one LS? This was my other thought of using Prism & MEF.

    I had been talking to a software company who have a [commercial] application done in late 80's and it needs to be redone and I think [in some cases] LS will speed the development, but this app is very large to write it as a single app, but at the same time, when users go from module to module, certain data is shared so having an ASP.Net page as a parent to a bunch of [independent] LS apps isn't going to cut it.

    So, here are my two specific areas. Hope this clarified my question.


    WPF/Silverlight Insider
    Friday, November 12, 2010 4:05 PM
  • Ben,

    What I hope they do for V1 is to allow us to make our own Shells. If they do that I believe that a situation like you describe (break a big application into smaller pieces) can be done, for example, using DotNetNuke. as soon as I can shove a LightSwitch app into a DotNetNuke module... well game over :)

    This will allow you to make a separate LightSwitch app for each "section" of the larger application, yet present everything on one website.

    So, I am actually not getting any warm fuzzy feelings about them adding actual extensibility points other than the ones they currently have (The Shell extensibility points already exists, they just haven’t allowed 'us' into it... yet).

    The reason I am not excted about additinal extensibility points is that the ones they have can be mastered quickly.


    http://www.adefwebserver.com

    http://lightswitch.adefwebserver.com

    Friday, November 12, 2010 4:56 PM
  • Mike, using ASP.Net or DNN as the main container isn't what many software companies going to use for a commercial modularized app, since this is not a website but rather a web application that runs over the web in 3-tier mode. Based on the license of the user different parts/modules will be active or inactive and the shell/container maintains and displays shared data in a dashboard. They initially were going to do it in WPF & SL, however it will take too long to build all the framework, plumbing and forms (over 1200 forms/screens, not counting reports). So, I invited them to look at LS and their team has been very positive about using LS as the framework. But, the discussion led to using Prism/MEF to create modules or extensions and that's why I posted the question.

    They're not even considering using DNN or ASP to act as a shell or container!


    WPF/Silverlight Insider
    Friday, November 12, 2010 6:10 PM
  • Right, I see your point I was only thinking of the 3-tier situation.

    To make the 1-tier and 2-tier easily configurable... man that is a tough one...

    The security seems to be the issue. For example with the 3-tier, I am planning on turing OFF the LightSwitch security.


    http://www.adefwebserver.com

    http://lightswitch.adefwebserver.com

    Friday, November 12, 2010 6:48 PM
  • There are two ways to read your question.

    The first asks if users of LightSwitch need to use or even be aware of MVVM, MEF, PRISM and the like either to use the product or especially for extensibility. The answer is definitely no on MEF: V1 extensibility handles all MEF goo for you. Of course the answer is yes for MVVM if a person does their own Silverlight, since MVVM is the Silverlight model. The answer is no for PRISM, as there are no hook points that expect or require PRISM to be a part of the mix. (Neither does it block use of PRISM though.)

    The second read of your question asks if clever folks who want to make LightSwitch do things it isn't built to do directly might find a way to achieve their goals with creative use of MVVM, MEF, PRISM and the like. The answer to that is perhaps--it depends upon what you want to do.

    The particular scenario you mentioned was modularity. The black and white answer is that there will not be hook points for the kind of modularity you want in V1. The best way to do that is probably the container approach you and Mike were discussing, though of course that has limits as you've pointed out. Some of the bugs we're fixing in B1 let you solve some of the problems (e.g. in auth) that prevent a clean container story, but I want to emphasize that they're bug fixes, not features.

    Steve

    P.S. I should add that LightSwitch locks down its use of MEF for the most part.

    • Marked as answer by Ben Hayat Sunday, November 14, 2010 10:15 PM
    Sunday, November 14, 2010 10:08 PM
    Moderator
  • Man, this is the best Sunday I've had for a long time. Got most of my serious questions answered by 'D' man himself :-) Thank you Sir!

    My question was related to the first part that you expertly answered. Trust me, I just want to stay within the LS and you guys can do all the MEF, Prism stuff all day long and I can focus on my Domain. This is good news for some prospects...

    For the second part, I'm not going to rock the boat [yet] :-)

    On the modularity note, fair enough and I honestly wasn't expecting any resolution for V1. But PLEASE hold this on the top of your list. I'm preaching this product to some people who will end up using it for some serious projects.

    ..Ben


    WPF/Silverlight Insider
    Sunday, November 14, 2010 10:23 PM
  • >> Our intention is that MEF is our implementation detail, and not something LS customers think about.

    If LS customers include code developers, please rethink your strategy regarding MEF, please.

    LightSwitch should NOT ban developers from using MEF in their domains.

    All my modules and libraries are based on MEF and I can not think of writing codes not using MEF.

    My MEF components do not need to mix with LightSwitch components. But we should be able to use MEF within our dlls at least.

    Unfortunately LightSwitch does not allow me to call this critical MEF line at the moment. So no [Import]/[Export] are supported.

        CompositionInitializer.SatisfyImports(this);

    To me being able to call this line of MEF is a critical deciding factor in choosing LightSwitch.
    If technically possible, please allow [Import]/[Export] from version 1.

     

    • Edited by reachpoint Tuesday, November 16, 2010 2:47 PM typo correction
    Tuesday, November 16, 2010 2:44 PM
  • What is the error you're seeing? Provide as much detail as you can so we can help diagnose the issue.

    LightSwitch doesn't actively block use of MEF, but the default configuration may not be what you expect because LS uses MEF extensively itself.

    Steve

     

    Tuesday, November 16, 2010 5:51 PM
    Moderator
  • Yes, MEF works!!!

    >> LightSwitch doesn't actively block use of MEF, but the default configuration may not be what you expect because LS uses MEF extensively itself.

    You statement gave me confidence and I tried it again. It worked!!! The issue was just my way of using MEF.

    So standard MEF usage as below works with no problem. Fantastic.

    using System.ComponentModel.Composition;
    
    namespace MefModule1
    {
      public partial class Mef1 : UserControl
      {
        [Import]
        public MefClass1 _mef1;
    
        public Mef1()
        {
          InitializeComponent();
    
    
          CompositionInitializer.SatisfyImports(this);
    
          if (_mef1 != null)
          {
            Text1.Text = _mef1.GetMefText();
          }
    
        }
      }
    
      [Export]
      public class MefClass1
      {
        public string GetMefText()
        {
          return "MefText1";
        }
      }
    }
    
    Tuesday, November 23, 2010 12:19 AM
  • What an amazing thread !!!!!!

    wonderful reading !!! thank you all

    Thursday, April 14, 2011 10:53 PM
  • I wonder if anyone today has been considering using Dynamic Regions from Prism 4 in LS Custom Controls.

    Prism 4 was released about the time that Ben started this post.  IMHO, Prism 4 was more of a rewrite than a version release from Prism 3.  Also, IMHO, Prism 4 did much to better define MVVM.

    Friday, April 15, 2011 2:03 AM
  • Hi Ben/Steve,

    The very fact that LS does all it's "magic" with MEF, PRISM, MVVM etc is exactly how I came to discover it.

    I was trying to teach myself all of those particular technologies, & learn how to effectively use them together, in WPF.

    Along came LS & I didn't have to worry about all that plumbing any more! :-)

    I could get on with the part I love, the actual business programming.

    Yann


    Friday, April 15, 2011 2:23 AM
  • there was no Prism 3. It went from 2 to 4.
    Friday, April 15, 2011 4:36 PM