locked
C# IoC within a Javascript Windows Store App

    Question

  • I was wondering if anyone is aware of a way to use an IoC within a Javascript Windows Store app, specifically where types should be registered.

    I'm familiar with the usage of DI/IoC through ASP.NET MVC, this has specific 'app start' type hooks where it's sensible to register types and I've seen a few posts on SO regarding the usage of the IoC containers using C# XAML windows store apps, but nothing for the Javascript equivalent.

    What I was hoping to do was create some windows store class libraries for application logic and data access and then access these from a Javascript store app front end. I'd like to be able to use DI to provide repository implementations at runtime for data access for example, but unsure where it's best (or even possible) to define these dependencies and at what point in the app I can instantiate them.

    At the moment, having found no obvious solution I'm guess that I will need to create a class library with a kind of 'init()' function that I call from the Javascript front end when it starts up to register the types.

    Does this sound like a sensible option? any other ideas/thoughts greatly appreciated.

    Wednesday, February 06, 2013 8:13 AM

All replies

  • Hi dougajmcdonald,

    In order to better help you with your question, I'm trying to involve some senior engineers into the issue and it will take some time. Your patience will be greatly appreciated.

    best regards,


    Yanping Wang
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, February 08, 2013 3:36 AM
    Moderator
  • Hi dougajmcdonald,

    Yes, the current support on DI/Ioc in javascript (especially for windows store app) is still quite limited, through javascript already has quite rich support on advanced OOP like programming syntax.

    And I think your current plan about encapsulating the DI/Ioc specific class and code logic in a separate library (Windows Runtime library) is reasonable. So far javascript based Windows Store app only supports Windows Runtime library. We can use either C++ or .NET (C# or VB.NET) to create windows runtime library. And you can create a C# windows runtime library so that the DI/Ioc specific code logic will be easier to implement with the .NET/C# language. In addition, we also need to take care on the types/classes we want to expose (from windows runtime library to the javascript windows store app) since Windows Runtime library has strict requirements on the types/data exchanged between windows store app and windows runtime library (doesn't like normal .NET class library which can let 's define and expose arbitrary .NET types)


    #Creating Windows Runtime Components in C# and Visual Basic
    http://msdn.microsoft.com/en-us/library/windows/apps/br230301(v=VS.85).aspx

     


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, February 08, 2013 3:44 AM
    Moderator
  • @Yanping Wang, thanks for that I will hang on as long as possible. 

    @Steven Cheng, thanks for the feedback, yeah it did seem to be a reasonable approach as far as I could see it. What I was hoping was that I could create a three tiered architecture with a C# (Windows Store) class library (for data access) which would provide data to a Windows Runtime Component (service/BLL layer) which would then be accessed through a JavaScript store app.

    The issue is that there's no obvious 'start' point to fire up the DI/IoC container binding code. I'm assuming the JavaScript app serves as the start up project, so I'd need to just manually call a 'setup/init' type function in say the startup code of the first page of the js app to call all the way down to the service and data access layers to ensure their types are provided through the IoC container correctly. 

    I think the types returned wouldn't be too much of a problem as I'd only be returning list of 'view model' type objects. Whilst it would be preferable to be able to return those as strong types, if I have to provide the data coming in and out as primatives and map them when they arrive and leave I could do that. 

    Worst case would be needing to revert to a XAML front end, but we have limited in team knowledge in terms of the XAML side of things, so if possible it'd be preferable to keep to the JS client app.

    Friday, February 08, 2013 10:14 AM