A few months ago we were sitting around as a .NET team discussing how we need to structure our development process. One of the main topics was how the .NET project structure should be done. At TheFARM we’ve had a fairly good project structure for a while, but we needed to better quantify it.

We structured all projects with a similar .NET internal set in the format of:

• Abstractions of our models and data services
• Concrete implementations of each
• Web usage of each

The problem was explaining it to a new developer, how do you say “Our structure is around …”?

So while sitting around discussing this we decided that we should give it a name. We like names here at TheFARM, especially fun names. This site is FarmCode, Suite101 is our business blog, and we have fun names for many of our internal systems.
It was only fitting that we think up a name for our .NET project structure.

Now I must clarify, we hadn’t been drinking (or at least not as far as I can remember) when we were having this discussion, we were just throwing around ideas for anagrams which we could use. I don’t rightly remember what else we had, but eventually we settled on FADS, or theFARM’s Abstracted Data Services.

Tacky, maybe, but now it’s named, so it’s easier to say “With FADS, where should X be?”, or as we’re currently discussing “How should we DI FADS?” (yeah that’s right, let's get as many anagrams into a sentence as we can :P).

What’s the goal of FADS?

The primary goal of FADS is to separate the data layer away from anything else, making unit testable development a lot easier. Your web layer doesn’t have any access to the underlying data layer(s), not does it have access to the actual .NET classes which represent the data layer.

Everything you do with FADS is done via interfaces. The data layer exposes interface so you can only access the data via them. The beauty of this is that you can refactor your data layer as much as you like, but not have the web layer any the wiser.
In fact, this happened recently with a project where we decided to swap out a data layer which was using the Umbraco XML as the data store for Examine. The web layer was unaware of any changes, except for the fact that everything started working a crap load faster!

Since FADS is just a design pattern it is quite acceptable with any .NET project, be it a standard ASP.NET WebForms application, an Umbraco-based application or even a non-web application.