Announcement

Collapse
No announcement yet.

ObjectLiteral vs "regular" objects

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • ObjectLiteral vs "regular" objects

    Hi,

    Before V16 it was required to use the ObjectLiteral attribute to send and receive objects over the network. Now in V16 you have fundamentally changed the way properties are implemented on the JS side.

    So my questions:

    1. Can I safely remove the ObjectLiteral attribute for my internal classes and still serialize / deserialize them properly ? (my tests so far show that that's the case, but I'd like to be aware of all consequences)
    2. In which cases is the use of ObjectLiteral still recommended or even required? The line between ObjectLiterals and regular objects has been blurred (in a positive way!!) and I need some direction as to when to use which...

    Thanks a lot!!
    Marco

  • #2
    Hey Marco,

    I am currently working on a project that allows you to invoke methods and parse arguments via Bridge.Net and return Objects base Serializing/Deserilizing.

    What I did, To make things work Correctly is this.

    Here is a simple Server side Json settings

    
    public static readonly JsonSerializerSettings JsonSettings = new JsonSerializerSettings()
            {
                TypeNameHandling = TypeNameHandling.Auto,            
                Formatting = Formatting.None,
                NullValueHandling = NullValueHandling.Ignore,
                ReferenceLoopHandling = ReferenceLoopHandling.Ignore,
                PreserveReferencesHandling = PreserveReferencesHandling.Objects,
                TypeNameAssemblyFormatHandling = TypeNameAssemblyFormatHandling.Simple
            };
    Here is my Javascript/Bridge/c# settings

    public static readonly JsonSerializerSettings JsonSettings = new JsonSerializerSettings()
            {
                TypeNameHandling = TypeNameHandling.Objects,                                    
                NullValueHandling = NullValueHandling.Ignore            
            };
    I am able to use complete CSharp Objects even inheritance.

    When i send the data to the Server.

    // Data inside the Ajax Query
    Data = method == null ? string.Empty : JsonConvert.SerializeObject(method, JsonSettings),
    DataType = "text",
    // Make sure the DataType is Text, so that jQuery Doesn't Serialize for you
    ContentType = "application/json",
    Type = "POST"
    When the Object comes back, I use:

    // o is the return object from the server.
    o = JsonConvert.DeserializeObject((string)o, type, JsonSettings);
    Works pretty good,
    Also the Serializing/Deserializing the objects doesn't seem that slow.

    It is really handy to make the Namespace for your core library the same as the Client/CSharp Side

    Example of project Flow

    Core (CSharp) - // All Objects,Models - Namespace SomeApp
    Server (CSharp) - Has Reference to Core - Namespace SomeAppServer
    Client (CSharp/Bridge) Has Linked Files for all Core Classes. - Namespace SomeApp

    The Only Problem is having to Manually Add the Link Between Core and Client.

    I am currently using this in a Business Management Software that should be ready at the end of the year.
    Last edited by geoffrey.mcgill; 2017-09-08 @ 07:12 PM.

    Comment


    • #3
      Hi Samuel

      Thanks for the detailed information, very interesting! Sounds like we're doing something similar with Bridge. I'm working mainly on a base framework for building business applications on top of it.

      I haven't had much luck with the new Newtonsoft-implementation of Bridge, because it doesn't seem to like nullable types. Example: When I have a class like this:

      public class Person
      {
         public Guid? Id { get; set; }
      }
      then Newtonsoft won't serialize/deserialize properly. This even seems to be a problem in the full implementation on the server side. Have you had any experience with it?

      I'm using the same project structure / princible to share classes between Bridge and Server. Just curious: Could you pose one example of a DTO class that you're sharing. I'd be interested to see what attribues you use / don't use.

      And finally: In V15 it was basically impossible to bind "real" objects to third party widgets; one hat to use ObjectLiteral to make this work, because the real objects only contained getters and setters, no actual array fields that stored the data. Now, in V16, this seems to be solved very elegantly, but I'm sort of "scared" to rely on this since I'm not sure how much I can rely on this new property feature. If you've made any experience with this, your help is greatly appreciated.

      Thanks!
      Best regards

      Marco

      Comment


      • #4
        Hi Marco

        I haven't had much luck with the new Newtonsoft-implementation of Bridge, because it doesn't seem to like nullable types.
        Can you share a Deck that demonstrates this issue?

        I'm not sure how much I can rely on this new property feature.
        The new real property getter|setter functionality is here to stay. It's very reliable.

        Comment


        • #5
          1. Can I safely remove the ObjectLiteral attribute for my internal classes and still serialize / deserialize them properly ?
          If you're passing around Type info in your JSON, then you likely do not require [ObjectLiteral].

          2. In which cases is the use of ObjectLiteral still recommended or even required?
          Applying the [ObjectLiteral] Attribute simplifies the syntax in the generated JavaScript. Generally this would be an advantage if you know you that you only require a simple object during runtime.

          If you need Type info or use Reflection, then [ObjectLiteral] is probably not required.

          Hope this helps.

          Comment


          • #6
            Marco This is an example of how I for instance, Save a Customer/Request to the Server

            // on the server
            Public GenericPayload Save(long Id, Document doc)
            {
            
            
            }
            
            // Document is a just a List of Objects.
            
            public class Document
            {
            public List<Field> Fields = new List<Field>();
            
            }
            
            public class Field
            {
            public string Name;
            }
            
            public class DateField : Field
            {
            public DateTime Value;
            }
            
            public class TextValueField : Field
            {
            public string Text;
            public long Value;
            }
            
            // etc any other types you need.
            Document Class would be in my Core Library and Client

            I have a few functions, GetField(string name)

            
            public Field GetField(string name); // if i return null - we have not sent that field
            // also i would have like
            public Field GetAndRemoveFIeld(string name); // removes it from the list
            
            // also easy functions to add
            public void AddComboValue(string text, long value);
            public void AddDateTime(string name, DateTime value);
            Then if i am saving to the database as we use Mysql - I just use that to create insert and update queries

            as i have all my designer code has a link field name - that i use to generate to generate the document class.

            doing it this way i had no issues

            I find it works fine for generics.





            Comment


            • #7
              [ObjectLiteral] is helpful if you need to pass an object to external API. For example, some external method which accepts config object and iterates it as a dictionary (key/value pair). In this case, you need object literal because class instance has a lot of additional fields and methods.
              Last edited by geoffrey.mcgill; 2017-09-08 @ 07:13 PM.

              Comment

              Working...
              X