This developer's chronicles

Web development using Scrum, C#, AngularJS and the like

Author: Harold Rodriguez (page 1 of 5)

Using Entity Framework code first from database

Entity Framework 6.1 came out with a feature called code first from database which allows you to reverse-engineer your database producing POCO classes from your tables (this was already present in Entity Framework as Database first approach). What is new if the fact that once the POCO classes have been created you can then switch to Code first, taking the current snapshot of the database as starting point of truth, from then onwards you can customize the database through code by applying migrations.

In the example below we’ll take the AdventureWorks 2012 database and we’ll use code first from database to create our classes, once we have imported the classes we’ll switch to Code First approach and we’ll add some data annotations to prettify our Classes names and properties as well as providing some extra validation.

Let’s start by creating a new web application in Visual Studio and selecting MVC as the template:

Creating web application project in Visual Studio


MVC template


Once the project is created and depending on the version of Visual Studio that you have installed you may need to update Entity Framework to at least version 6.1, right click on your solution and select ‘manage Nuget packages for solution’,  now select updates and finally select Entity Framework to check your installed version:

Verify Entity Framework version


Ok, now it’s time to get stuff done, let’s reverse-engineer our database (I like how that sounds):

  • Right click on your project and select Add -> New item
  • Choose Data from the left menu
  • Select ADO.NET Entity Data Model and add a name to your new model
  • Click Add

Add data model


  • In the next step  we select Code first from database.
  • Click Next

choose code first from database


  • Setup your db connection

setting up entity framework db connection


  • And now select the tables and/or views that you want to add and click Finish

entity framework choose database objects

That’s it !. Entity Framework will now have mapped the selected tables/views to POCO objects (bear in mind that views are treated as tables) as well as setting up your DbContext and connection string in your Web.Config file.

An example of a mapped table is the Address class (see below how Entity Framework read the schema definition of the table and added the necessary data-annotations to ensure valid data is stored into the table)

entity framework mapped poco  object class

If you haven’t seen the virtual keyword before it’s just the way how we can tell Entity Framework to lazy load in this case, the collection of BusinessEntityAddresses associated to a particular Address.

The last thing to do is to clean up property names to ensure a consistent name in our application (use the ‘Column’ data annotation to change the name of your property while maintaining the name of the column):

data annotations


In a later post I will show how to use migrations to make changes to your model and have that reflected in your database


Below are great links about Code first from database:


How a coding bootcamp boosted my professional career

I recently completed an intense 9 weeks coding bootcamp called FireBootCamp at SSW’s office in Sydney and today I wanted to share my experience about how it changed my perspective about software development as well as to hopefully encourage people out there (who are looking for ways to improve their skills) to go ahead and join one.

Why join a bootcamp?

Technology in general changes at a very rapid pace and specially if you are a developer you need to be ahead of the game, some of the things I’ve done to try to achieve this are:

  • Read blog posts and tutorials about -insert language here- and new frameworks -insert framework name here-.
  • Watch hours of Pluralsight videos.
  • Follow influential people on Twitter.
  • Attend different usergroups.
  • Work on personal and open-source projects.
  • Practice, practice and more practice.

While all the above has greatly helped in my short career I felt that something was missing, I knew I could build things that worked but I was mostly copying someone’s code without fully understanding what was going on or why things were the way they were.

This is where the bootcamp fitted perfectly in, it did not only break things down so I could digest them easier but it also showed me the big picture and provided me with enough exposure to problems (and ways to solve them) that everything clicked and started to make more sense.

What is SSW’s FireBootCamp?

SSW’s firebootcamp is the best way to increase your skills in an incredibly short amount of time, it’s 9 weeks where you’ll  learn better ways to build maintainable and scalable software, better ways to improve as individual and enhance your communication and presentation skills and better ways to collaborate with your co-workers, clients, product owners, etc; and all that while using the latest and coolest technologies!

A rough overview of what we saw during those 9 weeks is below:

  • Scrum: This was probably one of the biggest take away for me, we learnt how to inspect and adapt to the ever-changing software requirements, how to deliver software faster and continuously by getting early and regular feedback from the product owner and stakeholders, and by following the Scrum guide and all its events.
  • Enterprise architecture: We developed a real application using the Onion Architecture, but most importantly we looked into why it was important to have an architecture, its pros and cons and how to future-proof your applications.
  • Patterns and best practices: We covered a great deal of patterns  and best practices aimed at building more robust applications, some of them were Inversion of Control and Dependency Injection, the repository pattern and SOLID principles.
  • Full stack development: Not only did we dive into ASP.NET MVC 5 as back-end framework but we also covered Web API and Entity Framework as well as AngularJS and Kendo UI on the front-end, oh and how to forget TypeScript !.
  • Continuous Integration and Continuous delivery: Deployments were one my biggest pains of all time but we learnt the right way to do it by integrating TFS (Visual Studio Online) as a tool to automatically build our code and run unit tests against it with Octopus Deploy to automate our deployments to Azure.
  • Soft skills:  also one of my most improved areas as I realised how important this is for our success. The days were developers sat on a dark corner are long gone so if you want to be successful you need to be able to communicate effectively and clearly (we had a lot of practice on presentation skills and how to market ourselves as developers; that is why I started writing this blog after we watched a video by John Sonmez).
  • Talks by industry leaders: Once a week we would have speakers come and talk to us about different technologies, we had Andrew Coates talking about Azure, John Bristowe from Telerik, Paul Glavich talking about WebAPI and SSW’s Duncan Hunter with TypeScript, Adam Cogan with Scrum and last but not least our awesome mentor Gerard Beckerleg from whom I learnt the most.

I’m sure I am leaving a lot of interesting stuff out but you’ll hopefully get the idea of what this bootcamp is about and how it can help you increase your skills.


Final day and presentation

As if 9 weeks of coding and learning better ways to craft software was not intensive enough we were also asked to give a talk on the last of day of the bootcamp about a topic we really enjoyed and which had been beneficial (and it was in front of potential employers!). I chose Continuous Integration and Continuous Delivery with TFS and Octopus Deploy as it really took the pain out my deployments, below is a picture of my presentation !

Continuous Integration - coding bootcamp - SSW Harold Rodriguez

So if you are serious about your career and are looking for a way to increase your skills then SSW’s firebootcamp is the best way to achieve it!.

I’d love to hear your comments or if there is anything you’d like to have included in this blog post let me know.

View project dependencies with Resharper

Today while learning about Dependency Injection I found out a very neat way to view project dependencies with Resharper.

Using Resharper

For the developers who aren’t familiar with Resharper it is an awesome Visual Studio extension that will help you code faster and it will suggest code improvements as well as tons of shortcuts, navigation features, code refactoring, code smells, etc, etc (I even met a Senior developer who wouldn’t help me with my code unless I installed Resharper on my machine)

Ok, back to the project dependency analysis !

Resharper can build a dependency graph based on the references found on each of your projects, this can be a huge advantage as your solution grows or if you’d like to have a bird’s eye view of the current state of the project and whether projects depend on (or have references to) projects that they shouldn’t.

The next project dependency graph was taken after following an Introduction to Dependency Injection (DI) using the Onion Architecture by Adam Stephensen

Resharper project dependency graph


From the above we can see that there are no circular references in our solution and that there are not unintended references either.

Resharper will also let you visualize transitive dependencies or coupling between projects amongst other useful features.

To visualize your solution dependencies go to Resharper -> Architecture -> View Project Dependencies.

Using Visual Studio

Visual Studio (Premium or Ultimate editions) also bring dependency graphs to the table, the following is a dependency graph for a similar type of project (using the Onion Architecture)

Visual studio dependency graph


For more comprehensive information about these architectural tools be sure to read Adam Stephensen’s blogpost as well as Channel’s 9 video on Understanding your code dependencies through visualization

What other tools do you use for identifying code dependencies?

Using $scope.$apply in AngularJS

In order to understand what $scope.$apply() gives us and why we would need it  is necessary to take a step back and look at they way AngularJS checks if there has been any changes to its model or its views so that it can update its bindings (and the whole process that goes behind it).

Digest cycle

In AngularJS there is a concept of digest cycle, which is pretty much a loop in which AngularJS checks for any changes to its bindings plus anything else that is being watched and lives inside its $scope (note that not everything that lives inside the $scope is being watched by Angular, only variables used in expressions such as  <div>{{message}}</div>and also when $scope.$watch is being used.)

Once a watch is fired Angular starts a new cycle ( $digest cycle) in which it checks all current variables and compare them with their previous values, if it finds any change it will then update the correspondent bindings,  if it doesn’t it will then wait until the next watch fires.

Why do I need $scope.$apply() then?

Angular only monitors variables used in expressions and anything inside of a $watch living inside the $scope. So if you are changing the model outside of the Angular context you will need then to call $scope.$apply() for those changes to be propagated, otherwise Angular will not know that they have been changed thus the binding will not be updated.

Let’s look at the below example were I’m changing the model from outside the $scope therefore any changes that I make are not visible

And this is the code in my view:

The above JavaScript code will update the model two seconds after the page has been loaded, but as this is not being watched by AngularJS (the $scope.message is but not the timeout function) no changes will be visible on the screen

So if we want the changes to be propagated we’ll need to call the $scope.$apply():


If you are changing your model outside of your AngularJS context (or the variable that you want isn’t being watched) then you will need to use $scope.$apply in AngularJS as a way of telling it that it will need to fire a new $digest cycle so that it can detect your changes.

What is the difference between IEnumerable and IQueryable?

IEnumerable and IQueryable may seem like the same at a quick glance, but there are important differences that us, as developers must be aware so that we not only get a working product out the door but also something that performs well.

What is IEnumerable?

Simply put, is something that let’s you go from one element of your collection over to the next (an interface that will provide you with an iterator that moves forward), an example of how you can declare and use IEnumerable is as follow:

As long as you are using a type that implements IEnumerable you will have the advantage of being able to iterate over your collection.

When can I use IEnumerable?

  • When you want to iterate over a collection (List, Arrays, etc.)
  • When you want to get all the results from your query and apply any further filtering once your collection has been loaded in memory.
  •  When you are using LINQ to XML or LINQ to Object.

What is IQueryable?

IQueryable is an interface that implements IEnumerable (and because it implements IEnumerable it means that it allows you to iterate over a collection plus some more)

IQueryable takes Expression objects instead of delegates (which is what IEnumerable takes)

When can I use IQueryable?

  •  When you want to iterate over a collection (same as IEnumerable)
  • When you want to work with data from out-memory, such as a database, a web service etc
  • When you want to apply a filter to your query BEFORE the query is executed (this can save you heaps of resources)
  • When Lazy loading is needed (you only get what you need, not the entire list of records)

So… What’s is the main difference between IEnumerable and IQueryable ?

The main difference is that with IEnumerable you get all the records at once while with IQueryable you only get the records that you want, let’s see that in action with an example:

Let’s assume that you have a client table with all your client’s information (approximately 1000 clients)

  • If you use IEnumerable to get the first 5 customers you end up loading all 1000 and then selecting the first 5.
  • With IQueryable you only select the first 5 (saving a lot of resources !)

For some other useful resources you can check out some stack overflow answers and this dotnet-trick’s article on IEnumerable vs IQueryable


Thank you for reading, I hope you have now a clearer idea of IEnumerable and IQueryable and when each of them can be used best.

Older posts