On EF lazy loading and UML, EF and Serialisation

 

On EF and lazy loading and UML

A good few years ago (back in 2010) I looked at EF and one of my concerns was that you could not control the loading.  A had an object which had a collection of objects – like a car and wheels, and when I fetched the car the framework would not fetch the wheels at the same time – it went and got them one at a time.

This did not appear to be a scalable solution.

This time round things seem a lot better and I have been able to use the techniques here - https://msdn.microsoft.com/en-us/library/jj574232(v=vs.113).aspx – to control what gets loaded when.  Seems pretty neat.

I am fairly impressed with this as it allows me to decide what is always “Eagerly” loaded in the class model – what in OO days would have been an composite in my UML model and in the LINQ stuff optionally load the association.

On EF, Normalisation and Serialisation

I am using the EF (code first) objects as my “Business Objects”.  Not sure this has lead to massive time savings over raw ADO.NET as all that annotation is quite a pain.  Yes I could just generate the code (I started like that) but I use some pretty old school naming conventions on my database – Hungarian notation – because I’m old – so attribute names become compromised.

One of my other concerns with EF has been security but I’m assured that LINQ for EF will generate parameterised queries which are good (for security) and meet OWSA

So far I’m fairly happy that my object layer is not too normalised – but I’ve yet to tackle anything too serious – like inheritance and a class comprised of two tables.  Not sure about the former yet but a view will probably help the later.

A couple of things – if you are serialising (to JSON in my case for the service layer) then you need to decide how much of the tree you are bringing back and what you will serialise.

  [Table("tblEvent")]
    [DataContract]
    public partial class Event
    {
        [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA2214:DoNotCallOverridableMethodsInConstructors")]
        public Event()
        {
            tblEventParticipants = new HashSet<tblEventParticipant>();
        }

        [Key]
        [Column("intEventId")]
        [DataMember]
        public int EventId { get; set; }

        [Column("dtePlannedDate")]
        [DataMember()]
        public DateTime PlannedDate { get; set; }

       [Column("dteActualDate ")]
       [DataMember()]
        public DateTime? ActualDate { get; set; }

        [Column("intOrganiserId")]
        [ForeignKey("Organiser")]
        [DataMember()]
        public int? OrganiserId { get; set; }

        [Column("intRouteId")]
        [DataMember()]
        [ForeignKey("Route")]
        public int RouteId { get; set; }

        [DataMember()]
        public tblOrganiser Organiser { get; set; }

        [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA2227:CollectionPropertiesShouldBeReadOnly")]
        public virtual ICollection<tblEventParticipant> tblEventParticipants { get; set; }

       
        [DataMember()]
        public Route Route { get; set; }
    }

So I’m marking my classes with the  DataContract attribute, marking the members to be serialised with DataMember attribute and making sure they are always loaded by removing the virtual keyword (Eagerly loading) else the serialisation will fail.

One hurdle I’ve yet to cross is that I can see times when I may wish to load and serialise some of the associations – will need to work this through.