Now I need something more concrete to the project at hand. Still without any concrete implementations, I define another set of interfaces explicitly for the project’s data. There’s only a handful of entities in the project, so I can show most of it here.

The project is a relatively simple application that takes video or audio files and makes a podcast feed out of them. That’s all it really does, actually. I’ve simplified the model a little bit for brevity. In the data layer code I define the following XML file:

You’ll notice that there’s a few scalability problems with the way I’ve approached this. That’s fine for my project because it has a user base of 1 (me). It doesn’t need to scale, but if you want to adopt this approach for your own project, you’ll want to address these issues. My scaled down model basically has two entities in it, Feed and FeedItem. The properties match the database schema, which makes some of the implementation issues easier to surmount, but it certainly doesn’t have to match. Keep in mind though, we’re defining data objects, not business objects. To me it makes logical sense for data objects to follow the database schema. However, what we define here is all that the business layer is going to know of the data layer.

The next step could certainly be done by hand, but I decided to use a T4 template to generate the next set of code. Here’s a sample of the template:

And again for the Feed Item. This provides the business object with an interface that it can talk to for all CRUD operations, and interface for the DTO, and a simple concrete implementation that it can use when interacting with the interface. At this point, as far as unit testing is concerned, the data layer is done. I’ll cover some concrete implementations in the next post, but first there’s something missing. To be efficient about, for instance, a fetch operation, you want to filter the FeedItems returned to just the items related to the feed you’re instantiating. Notice that the generated Dal interface is partial. This allows me to add operations to it at the project level, so in another file I can add this:

Any concrete implementation of IFeedItemDal is now required to implement this method as well. In entity framework or linq to sql, you would accomplish this by writing a linq query against the model which in turn generates a sql statement to run against the database. This is still possible, but I’ve abstracted that down to the implementation. It’s certainly possible to do that, but a custom Linq provider was more than I wanted to get into for this project. Basically I’m taking the approach that the interface provides predefined queries and the implementation can accomplish them any way it wants to, including linq statements against EF providers. This is certainly extensible and could include custom types defined at this level for more complex queries.

The Mapper.Map line is AutoMapper. If you’re not using AutoMapper, check it out. It’s a life saver on this project. In this case, the DTO closely resembles the actual business object, so I can create a map without any custom mapping code. We’ve probably all written mapping code at some point in our career. I had one of my own that matched up the two objects based on property names and types and only copied the matches. AutoMapper does pretty much the same thing, but it caches the map and doesn’t do it every time which is a huge performance gain.

As you can see I pass my mocked IDalManager directly into ManagerInstance. What the business object calls will be the mocked object and get back whatever I tell it to return. The business layer is fully unit testable now. In my next post, I’ll cover some implementations of the data layer I’ve thrown together.

Fantastic items from you, man. I’ve take into account your stuff previous to and you are simply too excellent. I really like what you’ve obtained here, really like what you are stating and the best way wherein you are saying it. You make it enjoyable and you still take care of to stay it smart. I can’t wait to learn far more from you. That is actually a tremendous site.

It is currently as well as yet again complicated to merely always be giving freely alternatives that many a great many others could have been creating wealth through. We really recognize we have the blog owner to get thankful in order to for that. Khelomcx