Skip to content

Posts from the ‘Entity Framework’ Category

2
May

Upgrading from ASP.NET.Identity 1.0 to 2.0

ASP.NET.Identity 2.0 is out, and it adds a bunch of great features.

– Two-Factor Authentication (SMS, Email or custom)
– Account Lockout
– Account Confirmation via Email
– Password Reset
– Sign out everywhere
– Choose your Primary Key type (string, int, Guid)
– IQuerable Users and Roles
– Delete User
– Enforcing Unique User Names

 

The upgrade was more fiddly than I thought it would be. Here is what I had to do. I hope it helps.

 

1. Update Entity Framework to 6.1

2: Update all your OWIN components if they already exist in your project.

(Yes. NuGet should handle this for me. It didn’t. Upgrading the Owin components before the Identity packages resolved some issues for me)

image

 

3: Update Microsoft ASP.Net Identity Core and then ASP.Net Identity EntityFramework

image

 

4: Your model has now been updated to v2.0 !

If you are running Code First Migrations you now need to create a migration to reflect the changes to the database.

image

Figure: When you try to create the migration, it will tell you that the model backing the db context has changed. To resolve it, you need to update the constructor of your dbcontext.

 

image

Figure: Adding ‘, throwIfV1Schema:false’ as a parameter to the constructor will allow you to run the application, and create the required Code First Migration.

 

image

Figure: After updating the db context constructor, Add-Migration works as expected.

 

image

Figure: You can now inspect the changes to the schema in the Migration.

Upgraded !

Now check out the links below to get help on how to implement the great new features in ASP.Net Identity 2.0.

 

Resources:

ASP.NET MVC and Identity 2.0: Understanding the Basics

http://typecastexception.com/post/2014/04/20/ASPNET-MVC-and-Identity-20-Understanding-the-Basics.aspx

– a great overview of Identity 2.0

 

Announcing RTM of ASP.NET Identity 2.0.0

http://blogs.msdn.com/b/webdev/archive/2014/03/20/test-announcing-rtm-of-asp-net-identity-2-0-0.aspx

– definitely worth reading !

– contains list of features and some upgrade notes

4
Apr

Repository Encapsulation

It’s important to consider how strictly you should encapsulate your data access logic within the repository layer

Repository Layers allow us to abstract our data access away from our application.

There are two common approaches.

 

Approach #1: Fully Encapsulated – The Strict Repository

In this model you pass in simple types or DTOs as parameters to repository methods and receive enumerated lists of results in return. (ie. IEnumerable / ICollection / IList)

 

Benefit: Your data access is 100% completely abstracted away from your core application.
This model only requires the Entity Framework to be added to your Data project.

Cons: It’s more work. Every data access query requires a new repository method and a change to the interface.

 

Approach #2: The Flexible Repository

In this model you encapsulate complex queries, or queries that will be re-used inside your repository, but simple queries can be performed by the calling client because the Get() method accepts a filter operator and returns an IQueryable that provides great flexibility.

 

Benefit: It’s less work. A developer can build user interface that performs simple CRUD operations on the entity without needing to add methods to the Repository.

 

Cons: This is a ‘leaky’ abstraction where your implementation is likely to leak into your other layers. The Entity Framework is required as a reference in any project where you are performing queries that require EF specific extensions (e.g. .Include(c=>c.Children) )

 

For each application you need to weight the cons and benefits of the two options.

For a long-lived enterprise application, I recommend fully encapsulated repositories.

For simple applications that are essentially providing forms over data functionality, the flexible repository enables developers to quickly add value to the application, while still leveraging most of the benefits of implementing a repository layer.

 

TODO: Add Code Samples

6
Mar

Entity Framework Code First: Delete a LocalDb instance

When working with the Entity Framework Code First I will often get the error below:

An exception of type “System.Data.SqlClient.SqlException’ occurred in EntityFramework.dll but was not handled by in user code’

Additional information: Cannot drop database [database name] because it is currently in use.

To force a delete of the database, follow the steps below.

error_6-03-2014 11-04-30 AM

Figure: This exception is common after you have opened a LocalDb database in Visual Studio.

 

Open Library Package Manager and Stop the LocalDb instance

a: Select Tools | Library Package manager | Package Manager Console

b: Execute the following two statements

                  sqllocaldb stop v11.0

                  sqllocaldb delete v11.0

error_6-03-2014 11-05-59 AM

Figure: The steps above will stop and delete the LocalDb instance.

 

Delete the database file from the database

image

Figure: Open the Solution Explorer and choose Show All Files

error_6-03-2014 11-05-07 AM

Figure: Delete the mdf from the App_Data folder