The Database is just an Implementation Detail A quote from Martin Fowler given during his Architecture talk stated that the Database in your application should just be an implementation detail. I agree on this wholeheartedly and find that its really not that difficult to achieve if you think about your architecture carefully. Having said that, I still see parts of the database implementation leaking out into the domain, mainly in the form of IDs....
While writing my CruiseCli project, I needed to do some data storage, and so used my standard method of filesystem access, the IFileSystem. This is an interface and implementation which I tend to copy from project to project, and use as is. The interface looks like the following: public interface IFileSystem { bool FileExists(string path); void WriteFile(string path, Stream contents); void AppendFile(string path, Stream contents); Stream ReadFile(string path); void DeleteFile(string path); bool DirectoryExists(string path); void CreateDirectory(string path); IEnumerable<string> ListDirectory(string path); void DeleteDirectory(string path); } And the standard implementation looks like the following:...
When it comes to configuring StructureMap, it supports the use of Registries. Registries support everything that the standard configure method does(new Container(c => { /* */});). There are two main reasons that I use the registries rather then doing all my configuration in the Container’s lambda: separation of concerns (one registry per area of code) and easier testing (which we will go into shortly). The only down side I can see to using registries is that it can scatter your configuration across your codebase - but if you have ReSharper, doing a ‘Find Implementations’ on Registry will find them all for you, so it really isn’t much of a down side....
The term Rich Domain Model is used to describe a domain model which really shows you how you should be using and manipulating the model, rather than letting you do anything with it. It is the opposite of an Anaemic Domain Model, which provides a very low abstraction over the data storage (generally), but with little to no enforcing of rules. The Anaemic Domain Model To take the standard model of a person who has addresses and phone numbers etc seems a little contrite, so lets run through an example using timesheets (bear in mind I don’t know what really goes into a timesheet system, this just seems reasonable)....
One of the databases I use on a regular bases has a rather interesting column naming scheme; all columns have a prefix, based on the table name. For example, the table containing people would have the prefix PEO_, so you would have this: Select * from People PEO_PersonID, PEO_FirstName, PEO_LastName, PEO_DoB ----------------------------------------------------- 1 John Jones 1984-07-15 I believe the idea was so that when querying, you would not have any column name clashes....
Single Responsibility | Open Closed | Liskov Substitution | Interface Segregation | Dependency Inversion The Dependency Inversion Principle states that “Depend upon Abstractions. Do not depend upon concretions”. A good real world example of this is plug sockets around your house; any device you buy can be plugged into any socket in your house. You don’t have to buy new set of devices when you move house, and you don’t have to buy a new house for your devices!...
Interface Segregation Principle Single Responsibility | Open Closed | Liskov Substitution | Interface Segregation | Dependency Inversion Interface Segregation I find is often ignored, or people tend not to see the point in. Segregating your Interfaces is a very useful way of reducing compexity in your systems, and comes with a number of benefits, such as making mocking inputs easier, and making your objects smaller and simpler. So as usual, lets start off with an set of types which don’t adhere to the principle....
Liskov Substitution Principle Single Responsibility | Open Closed | Liskov Substitution | Interface Segregation | Dependency Inversion The Liskov Substitution Principle is states: If S is a sub-type of T, then objects of type T maybe replaced with objects of type S At face value, it means that a small class hierarchy like this: public class FileEntry { } public class DbFileEntry : FileEntry { } And a method which takes in a FileEntry, can be called like this:...
Open Closed Principle Single Responsibility | Open Closed | Liskov Substitution | Interface Segregation | Dependency Inversion The Open Closed Principle is one that I often find is miss-understood - how can something be open for extension, but closed for modification? A good example of this principle being implemented cropped up at work a while ago, we had a UI element which has a reusable grid, which gets populated with data based on a menu selection....
Single Responsibility Principle Single Responsibility | Open Closed | Liskov Substitution | Interface Segregation | Dependency Inversion SRP (Single Responsibility Principle) is something I hear a lot of developers agree is a good thing, but when I read their code, they violate it without realising, or don’t see the use in their particular case. A particularly prominent example I find in our code bases is Permissioning and Caching. These two requirements can often slip into classes slowly - especially if requirements are not clear, or change as the task progresses....