Home > English > Introducing Gofer – Getting Back to Basics

Introducing Gofer – Getting Back to Basics

One of the key driving forces for using Gofer is to allow developers to focus on business requirements and not worry about infrastructure and ceremony. The other motivating factor is to remove the overhead of maintenance and coding that is required to keep our domain models in sync with our database model or vice versus.

Let’s build a list of requirements that a good solid data access layer should provide:

  1. Easy to use API without the need for Attributes or custom coding in our domain model. We shouldn’t need to provide navigation properties or make our properties virtual just to get the data access to work.
  2. Convention-based rules implementation to provide the 80/20 rule of getting things right and allowing the developer to override the rules at the domain object/property level.
  3. Provide the ability to customize the SQL generation via templates. This will allow for each development shop to ensure that the SQL generated meets their coding standards.
  4. Allow the developer to shape their data requests in a compile-time friendly manner. This should be supported in the following areas:
    • Filtering options – we want to be able to use lambda expressions to allow us to filter our objects at pretty much any level of our object graph.
    • Load options – this allows the developer to use lambda expressions to define what objects they wish to eager load regardless of what level in the object graph.
    • Order options – this allows the developers to use lambda expressions to define in what order they wish to have their objects hydrated. This is very powerful in that we can order sub-collections all in a single request.
  5. Flexible coding strategy that supports both 2-tier and n-tier development. This means that we can use pretty much the same model to access data regardless if we are developing a Silverlight application or a WPF application.
  6. Ability to provide synchronization between the domain model and the data model. Should be able to provide a schema comparison and allow the developer to decide what to do. This means that we can do silent migrations or generate a SQL file for execution at a later time. You should also be able to force a migration whenever a data access operation is performed per the developer’s digression.
  7. Ability to trace to a log or console the SQL that get generated during runtime.

These are the ideal requirements that I have for my data access layer. I am sure many of you already see this answered in Entity Framework Code First or Fluent NHibernate but I wanted both an ORM and a transport mechanism in one. I also don’t want to deal with proxy classes when making requests over the web. That is why my solution uses HTTP Service APIs.

In the next post we will take a look at Gofer using a Console application.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: