NuGet Config File Transformation Causes Duplicate Entries On Update

Problem Overview

First off NuGet is great.  It has made life easier for me as a developer, and now, as an author for the open source generic repository SharpRepository.  It provides a great distribution channel, especially for providing updates.

The NuGet packages for SharpRepository add configuration elements to your Web.Config or App.config to make your life easier and allow for a configuration file way of setting up your repository.  NuGet provides a very simple configuration file transformation process when installing or updating a package. (For more information on it check here.) Basically it merges in your web.config.transform data into your web.config file adding the entries that don’t already exist.

Read more >>

Writing A Custom LINQ Provider With Re-linq

Overview

When LINQ was first released in 2007, I remember thinking that I wouldn’t use it and I was very happy using SQL for querying the database.  Well, once I started using it I really liked the ability to query lists, XML and SQL Server or other databases all using the same query syntax (for the most part at least).  When starting the generic repository idea that became SharpRepository, it became a logical choice to use.  If a backend had a LINQ provider then it became pretty simple to add it to our list of supported systems:  Entity Framework, InMemory, Cache, RavenDB, MongoDB, and db4o all had LINQ providers that we could find, whether they were developed by the same group or a third party provider.

At some point I started thinking, “how can we integrate with a technology that doesn’t have a LINQ provider?”  And the answer that came to me was, “I’ll just build one, it can’t be that hard right.”  Well, turns out, it’s not the easiest thing to do.  After doing some research, I came across this great article by Ayende Rahien about creating the LINQ provider for RavenDB and, as you can tell by the title, the difficulties which he faced: The Pain of Implementing LINQ Providers.  In it, he refers to the re-linq framework which takes some of the pain out of the process.

Read more >>

AutoMapper Profile Organization

AutoMapper is a great tool that I use on every project I’m involved in.  Primarily I use it to map my Model to my ViewModel when doing MVC development.  If you haven’t used it before, I highly recommend checking it out.

If you’ve used AutoMapper before on a larger sized project, then you’ve probably seen how long and unruly your mapping definitions can become.  This file can grow and grow and just be a pain to deal with.  Luckily, AutoMapper provides a way to separate the definitions up into more logical units.  When doing MVC development, it might be natural to group all the Model/ViewModel mappings for a single controller, but you can break it up however makes logical sense to you.  You would do this by creating a custom Profile for each where you define your mappings for those entities.

Read more >>

SharpRepository: Configuration

If you haven’t read my introductory post on SharpRepository you should give it a quick read as it provides a nice overview of the basic usage of SharpRepository.  In that post, I use the simplest method for creating my repository, I just new it up like so:

var orderRepository = new InMemoryRepository<Order>();

While this definitely works, it isn’t the best way.  Why?  Well, if you want to switch to an Ef5Repository or want to add caching, you will need to change the code and recompile.  Plus, you are using dependency injection and inversion of control right?  Well this doesn’t work with those patterns of course.   In this post I will cover some of the various ways to create your repository.

Configuration Overview

Before getting into the code for loading up a repository via configuration settings it will be helpful to understand the SharpRepository hierarchy.  Each repository has a specific type of backend that it queries (e.g. InMemory, Entity Framework, RavenDb, MongoDb, Db4o,  Xml, etc.), a caching strategy (e.g. None, Standard, Timeout), and a caching provider (e.g. Memory, memcached, Azure, etc.).

The caching strategy tells the repository the rules for caching.  The Timeout Strategy uses a simple time based rule, for example, cache the query results for 30 seconds, while the Standard Strategy uses Generational and Write-Through caching techniques to provide a more sophisticated caching logic.  And the No Caching Strategy does not do any caching at all (it’s not just a clever name).

The caching provider on the other hand is the specific cache technology that is used.  For simple websites the InMemory caching provider works great and uses the ASP.NET built-in System.Runtime.Caching.MemoryCache. For more advanced needs like distributed caching you would use the memcached provider or the Windows Azure provider and store the cache across multiple servers.

The beauty of this is that both of these can be extended by inheriting from ICachingStrategy or ICachingProvider if the need arises.

Read more >>

SharpRepository: Getting Started

What is SharpRepository?

I think this quote sums it up nicely, “SharpRepository is amazing!  I couldn’t have written the Gettysburg Address without it.  Plus it picked out this awesome hat.” – Abraham Lincoln

In reality, SharpRepository is a generic repository layer with many persistence implementations like EntityFramework, RavenDB, MongoDB, and InMemory to name a few.  SharpRepository abstracts away the technical concerns of your data layer by offering a common interface for dealing with your domain objects.  In non-technical jargon, it allows you to add, update, delete and find data that is stored somewhere else, where, it doesn’t really matter.  That is the beauty of it.

In this post, I will describe how to get up and running with SharpRepository and basic usage.  In future posts we will get into more advanced usage scenarios like caching, batching, testing/mocking, as well as get into the specifics of the different type of specific repository implementations.

Read more >>

Find Performance Problems Using JMeter, MySQL and Xdebug/Webgrind

On a recent project, I was tasked with analyzing an existing application and determining what could be done to improve its performance: meaning page load times.  The site was written in PHP with a MySQL database so I’ll focus this post on how I went about it for this set of technologies.

Baseline Metrics

With any optimization project the first thing you should do is create a set of baseline metrics for how the application is currently performing.  Why?  So you can take full credit for all the wonderful improvements you make, of course.  You’ll be able to say smart things like, “We were able to increase overall performance by 243.71%.”

A great open source tool for creating these baseline metrics is Apache JMeter (http://jmeter.apache.org/).  You can use JMeter for performance testing as well as load testing.  The basic idea is that you create a test plan and then tell it to run that plan for X users Y times each and it plugs away at it while keeping track of page load times along the way.  You can create a single test plan to go through all of the common actions within the application or create a different test plan for each logical section, it’s up to you.  I would start with a general plan that covers most of the application and then add more later if needed.

Read more >>

Write-through and Generational Caching Make a Great Team

We all know that a great way to speed up any website is to throw some caching at it, right?  When considering caching strategies there are a lot of questions you should be asking.  What type of caching is right for my specific situation?  Do we have to worry about serving up stale data, and if so how do we go about handling that?  Plus another dozen or so questions.  My goal in this post is to show a generic caching strategy that can be implemented in most web applications and just work.

Caching Considerations

“So what exactly are you looking for when it comes to a generic non-website specific caching strategy?” you might probably didn’t ask.  Good question.

1. Generic implementation
   By that I mean I can just throw it at any new project I’m working on and don’t have to customize it for the type of data I’m dealing with, or any specific cache implementation (i.e. Memcached, in-memory cache, etc.)
2. Stays out of my way
   I don’t want to have to specifically clear out the cache for my entity whenever it is updated, or manage cache keys to invalidate previous queries.
3. Don’t serve up stale data
   There are certain situations where stale data is acceptable, but for a generic implementation we want to be conservative and only serve up to date data.

There are 2 types of main data you will be dealing with in your application: single entities (think CRUD) and queries (give me all the posts in a category).  I’ll be dealing with these types differently.  For single entities, I’ll implement write-through caching and for queries I’ll be using generational caching.

Read more >>