Welcome to the first part of an ongoing series, Making Sharp Architecture 2.0. The goal of this series is to walk through the development of the next iteration of Sharp Architecture as it happens. We hope that increased transparency will give insight to design decisions and, more importantly, foster discussion on how to improve a great framework.

The series begins in medias res, as much work has already gone into the 2.0. To recap the current status of 2.0.

Project Structure Renaming

The current project structure follows the tenants of a properly layered design, but through accidents of history, does call itself by any standard naming scheme. This a quick one to knock out:

Why tasks and not application services? Services is, unfortunately, a loaded term. There’s Windows' Domain Services, Service Oriented Architecture, web services, and menagerie of other jargon that pulls and tugs at the meaning of service. Let’s go back to Eric Evans' definition:

“[The Application layer] Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks (emphasis mine) this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems.

"This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.“ (Evans 70)

The idea that the presentation layer calls tasks to be performed seems a much more natural fit for this.

The reasoning behind moving controllers from a separate assembly are two-fold. First, given that controllers are tightly integrated to the views they show, the separation seemed like a bit of needless abstraction. Second, rather pragmatically, moving controllers to co-habitate with views allows the built-in Visual Studio tools to function correctly. Moving controllers to a separate assembly, if you so desire, is a trivial task nonetheless.

Introduction of SharpArch.Features

One of the ideas presented by Sharp is that the persistence technologies themselves are fungible. There’s quite a bit of debate as to whether or not this is actually necessary. I will concede that most projects do not move from a traditional RDBMS to a document store without a major refactoring. If a project were to use a lot of different database technologies, due to its size or complexity, it would probably benefit from a more robust service bus and a move away from the repository pattern.

What would be beneficial, would be to start a new Sharp project with whichever database technology you want to use in easiest manner possible. This is the idea behind moving NHibernate and persistence frameworks to their own assembly with SharpArch itself being persistence ignorant.

Stepping back a minute, does pulling the persistence framework out of the core project violate good design principles? After much research, I don’t think so. In fact, it allows the other layers in Sharp Architecture to be even more loosely coupled. Larman prefers to put frameworks entirely as a “subsystem within the technical services layer,” (Larman 623) not tightly coupled with the rest of the project.

How tightly coupled is SharpArchitecture to NHibernate? As tight as one could be, even where it logically shouldn’t be. For example, since there is an NHibernateRepository and a Repository, you might conclude that the latter is a generic version of the former. That would be wrong, there’s plenty of pernicious little references to NHibernate everywhere. Take SharpArch / SharpArch.Data / NHibernate / Repository.cs:

public virtual IList<t> GetAll() {

            ICriteria criteria = Session.CreateCriteria(typeof(T));

            return criteria.List<t>();

        }

Session is not a generic session manager, but instead belongs to NHibernate.Session, and obviously CreateCriteria exists only in the context of NHibernate. This would make more sense if NHibernateRepository.cs didn’t also exist, which it does. Cleaning this up should go along way to creating a more persistence independent framework.

Conclusion

We moved to a better, more precisely named project structure. This has the advantage of allowing the built-in features of Visual Studio to work out of the box. We also looked at a major restructuring involving moving the persistence subsystem to its own assembly and keeping it from polluting the rest of the framework. Next time, we’ll look at implementing Udi Dahan’s Query<T> as a way of passing Linq fetch queries down to the persistence layer.

References

Craig Larman. 2001. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd ed.). Prentice Hall PTR, Upper Saddle River, NJ, USA.

Eric Evans. 2004. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley

This is cross-posted from my blog