locked
Is it possible to add extension methods to Lightswitch entities? RRS feed

  • Question

  • I find myself attempting against the rule DRY (Don't Repeat Yourself) when writing code in LS Applications.

    Is it possible to add extension methods to Lightswitch entities that are visible in all Projects (Client,Server and Common)?

    Wednesday, May 29, 2013 10:05 PM

Answers

  • Hi Jean Pierre,

    If you think it's not possible with LightSwitch then think again :)

    public static class Ext
        {
            public static void MyExtMethod (this Customer customer)
            {
                // ...
            }
            public static void MyExtMethodBasedOnIEntityObject(this IEntityObject entityObject)
            {
                // ..
                //var generalField = entityObject.Details.Properties["...].Value
            }
        }
        public partial class ApplicationDataService
        {
            partial void Customers_Inserting(Customer entity)
            {
                entity.MyExtMethod();
                entity.MyExtMethodBasedOnIEntityObject();
            }
        }


    paul van bladel

    Thursday, May 30, 2013 5:24 AM
  • Also, if you want to share that extension between the Server and Client and you don't want to go down the route of another common library, then you can add it to the Server project (for example) and add a link to it from the Client project. That works quite well as long as you don't use anything that is not portable in those extensions.

    Regards, Xander

    Thursday, May 30, 2013 6:50 AM
  • Hello,

    You don't need to put it in a separate solution, you can just add the library as an extra project in your LS solution. I can't see any advantage in keeping it in a separate solution.

    A portable class library is one that can be referenced from any type of .NET-based assembly, including standard .NET and Silverlight.

    If you are working in LS v1, you already have a common project, and so don't need anything else. If you are in VS2012, and don't have a common project, you can just add one. Whether you add a Silverlight or portable class library is up to you. The only real difference will be when MS finally drop support for Silverlight, but as that is going to be years away, it's unlikely to make much difference now.

    Hope this helps.


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Sunday, June 2, 2013 3:16 PM

All replies

  • Hi Jean Pierre,

    If you think it's not possible with LightSwitch then think again :)

    public static class Ext
        {
            public static void MyExtMethod (this Customer customer)
            {
                // ...
            }
            public static void MyExtMethodBasedOnIEntityObject(this IEntityObject entityObject)
            {
                // ..
                //var generalField = entityObject.Details.Properties["...].Value
            }
        }
        public partial class ApplicationDataService
        {
            partial void Customers_Inserting(Customer entity)
            {
                entity.MyExtMethod();
                entity.MyExtMethodBasedOnIEntityObject();
            }
        }


    paul van bladel

    Thursday, May 30, 2013 5:24 AM
  • Also, if you want to share that extension between the Server and Client and you don't want to go down the route of another common library, then you can add it to the Server project (for example) and add a link to it from the Client project. That works quite well as long as you don't use anything that is not portable in those extensions.

    Regards, Xander

    Thursday, May 30, 2013 6:50 AM
  • Dear Paul, Thank you very much for your code. Although we are using VB it was very helpful. In VB you must implement extension methods inside a Module. We added a Module to the Common project and there we implemented an extension method for a LS entity. The mentioned method is now visible from all three projects (Server, Common and Client) after building the application. Thank you very much. Jean Pierre
    Thursday, May 30, 2013 5:45 PM
  • Dear Xander, This was helpful. Thank you Jean Pierre
    Thursday, May 30, 2013 5:46 PM
  • You are most welcome.

    Consider also the advice from Xander, to not use the common project (in V3 there is even no common project) and use a simple file reference;

    kind regards

    paul.


    paul van bladel

    Thursday, May 30, 2013 5:48 PM
  • OK.

    We are still using V2.

    In V2 the Client Project has a native reference to the Common Project and it seems that the Server Project also has a native (but indirect?) reference to the Common Project.

    Any Cons and Pros between the two options ?

    1. Add the code in Common and not need to add any reference

    2. Add the code in the Server Project and reference it from the Client Project

    Thursday, May 30, 2013 6:16 PM
  • Both scenarios work and in V2 using the common project is the most comfortable option.

    But the most important contra is that you will need to upgrade your project when you move to V3.


    paul van bladel

    Thursday, May 30, 2013 6:20 PM
  • Paul,

    What's wrong with having a common project? I still can't understand why MS dropped this, to me it's a vital feature.

    Also, even if you upgrade, there's no reason why you have to lose your common project. Heck, even if you start a new project in the latest version you can always add one yourself.

    I really don't like the idea of adding a reference to the server project from the client. It breaks all sorts of design principles, and is just plain unnecessary if you add a common project.

    I would be interested to hear your thoughts on this.


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Friday, May 31, 2013 3:00 PM
  • There is nothing really "wrong" with using (or adding in case of V3) with a "common"project.

    But don't forget that the common project must be a silverlight assembly, which one day, unfortunately, will retire

    I really don't like the idea of adding a reference to the server project from the client. It breaks all sorts of design principles, and is just plain unnecessary if you add a common project.

    This is no violation of design principles. Remember, there is no binary reference from client to server (it wouldn't even work because a silverlight assembly can't reference a full .Net dll), but there is only a shared file (or multiple shared files) ,e.g. a file with a class or interface (and the file is added as "link", in such a way both files (in client and server) are always in sync. That's really super D.R.Y., like a good glass of sherry or Canada Dry :)

    Cheers !

    paul.


    paul van bladel

    Friday, May 31, 2013 4:22 PM
  • Hi Paul,

    Good points, although you don't have to use Silverlight for the common project. You can add a portable assembly, which (as far as I know) isn't going anywhere. The whole point of them is that they can be referenced from pretty much any kind of project.

    Also, by the time Silverlight is no longer supported to the point where you can't even reference an SL assembly, I think we will have gone so far that this discussion will be academic! We'll be using something very different by then. Bear in mind that MS invested a lot in SL, and even if they drop ongoing development, they would be very foolish to drop support for a long time.

    As a comparison, MS recently announced that they are extending support of VB6 for a few more years. This means that it will end up with something like 27 years of support after the product was officially dropped! SL might not get quite such a reprieve, but I think it will be around long enough for it not to be a problem.

    Of course, most of this is speculation! Thanks for the reply.


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Sunday, June 2, 2013 1:41 PM
  • Hi Mr Yossu: We make a portable class library project in an independant solution.Then we add references from all three LS projects (common, client and server) to it and we have visibility of our code everywhere. Question: What are the cons of this approach? What are the differences between a portable library and the others?
    Sunday, June 2, 2013 3:05 PM
  • Hello,

    You don't need to put it in a separate solution, you can just add the library as an extra project in your LS solution. I can't see any advantage in keeping it in a separate solution.

    A portable class library is one that can be referenced from any type of .NET-based assembly, including standard .NET and Silverlight.

    If you are working in LS v1, you already have a common project, and so don't need anything else. If you are in VS2012, and don't have a common project, you can just add one. Whether you add a Silverlight or portable class library is up to you. The only real difference will be when MS finally drop support for Silverlight, but as that is going to be years away, it's unlikely to make much difference now.

    Hope this helps.


    FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.

    If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/

    Sunday, June 2, 2013 3:16 PM
  • @Paul

    @Xander

    @Mr Yossu

    Thank you for your tips.


    Sunday, June 2, 2013 7:01 PM