Preparing for Dapper (Part 2)

It's time to replace a 10 year old "core architecture" with a modern version. The team decided on continuing to use stored procedures with the intent of keeping all business rules and logic in one place. Instead of going for Microsoft's Entity Framework, the team opted to use Dapper, a micro-ORM with lots of promise.

The new "core architecture" design goals are as follows:

• The team wants business logic and rules in one place.
• The team wants applications to be data source agnostic.
• The team wants to be productive, flexible, creative and inventive.

In order to accomplish these goals, these bullets need to be exploded in to details. The team pretty much has a plan already for the first bullet via stored procedures. For the second bullet though, knowing that the team will use C#, there's an obvious need to be able to represent the data models as objects first.

Call it anemic however you like, but I like them POCOs. They're clean, simple and straight to the point. The team agreed on using POCOs to represent our models in C#, and that was it. Their purpose is straightforward.

POCOs are basically classes with only public property members to which you can set or from which you can get values. They can represent the application's data models in to objects that can be easily created, manipulated and shared.

public class POCOName
{
    public int POCONameID { get; set; }
    public string Code { get; set; }
    public string Description {get; set; }
}

Dapper is a data mapper. For as long as our data source can be queried such that the returned fields names (or aliases) are matching our POCO's property names, there should be no need for manual mapping, which can greatly help in improving developer productivity -- allowing the team to spend less time detailing the dirty work and focusing more on the business requirements instead.

Being anemic, POCOs don't really know how to do anything. They only have attributes. They have no behaviors. They don't even know anything about the database, just like how the team also wants applications to be: data source agnostic.