Forkwind Part 1: Creating skeleton of the application layers as . net assemblies

This is the first part of our forkwind implementation. If you are not aware of the master thread and forkwind, please here first

As being pragmatic without diving into deep theoretical discussions we first create our project skeleton.


As seen in the picture our forkwind implementation consists of 8 projects which are also assemblies. If you are unfamiliar with assembly concept just hold your breath a while that we will discuss modularity and assemblies in the next part Forkwind: Part 2: Modularity, .NET Assembly and Namespaces.


Let's go through each assembly and discuss why we need them briefly:

Forkwind.Core: Obviously this is our core assembly. We are planning to put most of our business logic , our domain entities service layers here. One key point is Forwind.Core should not depend any other assemblies but be able to self compiled. In this case it only uses Forkw

Forkwind.Repository: The name repository may look unfamiliar to you. But this is simply an evolutioned version of your old data access layers or DAO's or what ever you call it. Why I call it Repository ? The simple answer for now is we have domain objects and one of our aims is to encapsulate data access as internals so that our application is unaware of the datasource. More details will come in following parts. Don't worry about it at the moment.

Forkwind.Presenter: This is our presenter layer. If you are unfamiliar for presenters their main job is to bridge the core layer and the gui. They prevent business logic leaking to UI layer.
It's mostly modeled after Martin Fowler's model view presenter. And again we will discuss it throughly. For the time being it provides a GUI agnostic backend , also enables us to unit test our guis.

Forkwind.Test: This is for unit testing obviously. I will use nunit but anyother unit test framework is ok.

Forkwind.Util: This is for general utility stuff. We can make use of C# 3.0 extension methods here as well. All other assemblies may make use of this assembly.

Forkwind.Web: This is our assembly for the web application (and not web site!!).

Forkwind.Console: This is our assembly for a console application which make uses the same backend. It's mainly demonstrative purposes so that it proves our implementation is GUI agnostic. But you can further improve it as you like


Forkwind.Windows : This is our assembly for a windows application which make uses the same backend. It's mainly demonstrative purposes so that it proves our implementation is GUI agnostic. But you can further improve it as you like.

SharedLibraries: This is not a project but a pile of third party libraries to be used by other projects.

Well that's it. Let's see the dependecy of our assemblies:


For simplicity I removed console from diagram but same as Windows and web. All assemblies except references Util. And Test references all other assemblies.

In old designs typically we have GUI -> Business -> Data Dependency. But this doesn't sound correct to me. If business depends on data then any changes on the data layer may break our business layer as well. This is totaly unacceptable. This is why the dependency is inverted here. And our core assembly is stand alone (except it makes use of util). This way it won't be affected of any changes happening in any other assemblies. We will get into details in the following parts so stay tuned!

Code is attached for this section here


Next part is : Forkwind: Part 2:Modularity, .NET Assembly and Namespaces