Entity Framework

blog-entity-framework1

On a recent enterprise ASP.NET MVC client project, I was introduced to using Microsoft’s Entity Framework for the first time. I was skeptical at first, thinking that an abstraction layer with LINQ over the database would slow things down performance-wise from the standard .NET calls to SQL procedures (there is a performance cost to using LINQ).  I have written and modified thousands of stored procedures, which work reliably well, but don’t have the same development, design, and maintenance advantages with LINQ, Entity SQL, and so forth.  Alternatively, using stored procedures requires a thorough understanding of SQL and the “impedance mismatch” between .NET object/procedural code and the set-based operations of a SQL engine.

I was blown away by the speed of the Entity Framework – honestly.  I’d never seen database transactions happen that fast when stored procedures were not part of the solution, and with Entity Framework, there is no need for a library of stored procedures.  Now part of it could have been the latest and greatest virtual SQL Server 2016 instances in use.

Setting that aside for a moment, I don’t know how one could go wrong with Entity Framework as a starting point for getting away from the standard repertoire (or jungle) of hundreds or even thousands of stored procedures, views, user-defined scalar and table-valued functions, all called from (usually) hand-coded DAL abstraction layers or form-classes in ASP.NET, WinForms, etc.  It’s typically quite a bit to manage on it’s own, and change-analysis on a database server is usually a very time-consuming and tedious undertaking, with or without the benefit of script source-control.  Entity Framework makes data-persistence much more manageable for everyone.

Industry was slow to adopt the Entity Framework due to performance bugs in the first versions. As as a result, Microsoft was forced to update it quickly, moving from v1 to v4 in fairly short order.  By the time the framework had evolved to version 4, industry adoption rates picked up pace and a few performance kinks were worked out.  As of early 2017, version 6 has been out for a while, and adoption is even better, for those enterprises that understand the benefit of adoption, and have the time and resources to implement it.

Benefits

  • One queries strongly-typed domain entities like: Customer, Order, LineItem, TimePeriod, etc.
  • It completely replaces a typical DAL layer.

Drawbacks

  • If any, the learning curve of using the many flavors of LINQ.

Summary

I have a very high regard for the Entity Framework 4 and higher (current iteration is 6) and look forward to using it in any client project where I can.

When you learn Git, get it right

Git-Logo-1788C

Having used Microsoft’s Visual SourceSafe for source control and then Microsoft’s Team Foundation Server (TFS) for most of my software development career, I was recently exposed to the many wonders of Git (open-source, distributed-control, well-tested and fast). At a client site, our team workflow was switched to Git right in the middle of a very important project, probably not the most optimal time to introduce a new source-control workflow, but oh well.  It was high-time to learn Git – trial by fire!

Centralized vs Distributed (the newer paradigm)

I had known of Git as a distributed source-control “system” for quite a while, but was never exposed much to it until I had worked for this client and the team had an urgent need to switch over to Git from TFS in order to enable four teams to work on several parts of one project all at once without corrupting each others’ code.  Contrast that with Microsoft’s Visual SourceSafe (VSS), Team Foundation Server (TFS) or CVS, which are products designed to centralized source control on one server.

Git is a fantastic (double-underline?) source-control system & represents the best of the newer paradigm of distributed source-control.  There is a steep learning curve (in my opinion) and a price to pay (in time) for using it incorrectly or not learning how to use it on a very simple project first.  The compensating factors are that Git is free, open-source, world-class, and fast. Some of the cloud-side, server-side, and client-side tools that support it are not free (most are though).  Either way, you should be using it now or very soon as it’s the present and future of source control.

Here are a few learning resources for your benefit:

I am using:

…to manage my Git repositories (repos). BitBucket is free for individuals and teams of up to five people; GitHub is similar.  GitKraken and TortoiseGit are both free to individual developers on their home machines. Aside from that, the purchase prices are reasonable for all of the above if a purchase is necessary for legal compliance. I don’t work for or receive compensation or recognition from either firm.

Summary:  Learn how to use Git thoroughly on a small non-critical or personal project with at least one other code contributor before attempting to use it on a enterprise mission-critical project.  I cannot emphasize this learning approach enough to save you from time-critical error fixes and just the hassle of having to go through it.