Monday 30 January 2017

ODBC Settings multuple servers

You need to have some wdac sdk on the server and each machine that you connect to.
$credential = Get-Credential
foreach ($server in @("ESS027521","ESS026412","ESS026488","ESS026191")) {
    $session = New-CimSession -ComputerName $server -Credential $credential
    $odbc = Get-OdbcDsn  -CimSession $session
    $server + ":"
    $odbc        
}

Tuesday 10 January 2017

EF lazy and Eager loading–caught out! (Putting lazy load back on)

I was a bit optimistic in my last post on EF.  Turing off Lazy Loading (removing virtual) on a attribute does NOT imply eager loading.  Documentation is unlcear but confirmed by internet -

“IMPORTANT: You could easily think that, once you disable Lazy Loading, the framework will auto-load each and every related property: it won’t.” - http://www.ryadel.com/en/enable-or-disable-lazyloading-in-entity-framework/

So I’m back to the .Include on each of my get methods to ensure consistency.

Not sure the argument “Don’t worry, it’s a good thing! You don’t want your DB to be automatically wasted on each Entity query request.” isn’t a bit of a cop out.  I want to decide which of my attributes are composite – think car and wheels – and load those all the time.

Of course – I can do this with the .Include but its a bit less explicit.  Making the attribute virtual again will at least means the serialisation falls over if I forgot to include the Lazy Load/Serialisation fails as it’s outside the context – so that at least enforces my aggregate.

Monday 9 January 2017

Hype driven development

Following on from Hype Driven Development (HDD) often implemented in CV++ – here is some more data, frameworks and api’s to consider:

-----Original Message-----

Subject: Amusing and/or point-making links for your arsenal!

http://foaas.com/

http://dayssincelastjavascriptframework.com/

http://www.ismycodeshit.com/

http://shouldiblamecaching.com/

http://vanilla-js.com/

http://shouldiuseacarousel.com/

Sunday 8 January 2017

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.

Saturday 7 January 2017

On very small tasks

Yes I am still going – and starting to get things done.  Spare time projects are hard to work on because code requires lots of long focus.  But, I’ve found that by really breaking down tasks (I believe they call that pebbleisation) to items taking less than an hour I can quickly pick things up and get something done.  On a full time project you can get the whole thing straight in your head and then go ahead and implement but when there’s days or even weeks between then you need to have really recorded what you were going to do.

 

image_thumb[7]