Previously
A code story staring MVP.NET - Introduction
Development Environment
Even in a solo developer project, I believe a source control system is extremely important. There are several free options to choose from (A few of them are SourceForge, CodePlex and Google Code), I created a new Google Code Project called phogaldotnet with LGPL as license.
Ideally I would want a Build Server and do Continuous Integration, but since I don't have a server, I can only set it up on my own machine. This is less optimal for a number of reasons (dependencies are already on my machine, its not online all the time etc.), so I have decided to skip this.
Tools
To start I will only be using the following tools:
If/when new tools are relevant, I will install them.
Mappings
I usually keep all OSS projects in this folder "c:\oss\", so I have created a folder for "phogaldotnet" so the full path is "c:\oss\phogaldotnet", and done "SVN Checkout" from "https://phogaldotnet.googlecode.com/svn/trunk/".
Additional installation
Download and install ASP.NET Extension 3.5 Preview for full VS 2008 support.
Solution and project structure
I like to have a folder called "Dependencies"(some call it "bin") with all the 3rd party dll's.
Also I downloaded the MVCToolkit and copied the dll and pdb files to the Dependencies folder.
A a SVN Add on the Dependencies folder and then a SVN Commit.
Creation of the Visual Studio solution and MVC project.
SVN Add (not the bin and obj folder) and SVN check in.
Namespaces
I named the solution "PhogalDotNet" and the web project "PhogalDotNetWebAccess", because I usually don't like sticking everything into 1 namespace (i.e."PhogalDotNet"). Application and components are two different things. Application is a single use of components configured for a specific need, and components are self contain units of logic that any number of applications can use.
The idea is that I want a separate project with the name "PhogalDotNet", that contains all the logic. I will hopefully end up with an application, that is consists of a web.config file with HTTPHandlers and HTTPModules and a connection string to a database. So I will slowly be refactoring towards that.
More than that, I don't like when types in a namespace reference types in deeper namespace. Ex.: "Root.Core" types should not reference types in "Root.Core.Specialized". But a reverse dependency from "Root.Core.Specialized" to "Root.Core" is fine.
I am even suspicious about cross references within the same root. Ex.: "Root.FeatureA" should not reference "Root.FeatureB".
Morten Lyhrs rules for namespaces:
- Don't mix application and component namespace root names.
- Every application should have it's own namespace root.
- Components can share a root.
- Types in a namespace should not reference types in a namespace below it's own.
- No cross references within the same namespace root.
For simple components I usually end up with the following namespace structure:
"ComponentRoot"
"ComponentRoot.Infrastructure"
"ComponentRoot.Infrastructure.Facade"
All types in "ComponentRoot" are POCO, I try to keep this as fat as possible. Ideally all if/else, loops and as much logic as possible should live here. Unit test(Fast tests) is min. 100% coverage! Extension points for non logic are created via interfaces or virtual/abstract methods.
Types in "ComponentRoot.Infrastructure" is the default infrastructure provided. It implements the extension points in in "ComponentRoot". Ex.: "ComponentRoot.MailService" interface is implemented by "ComponentRoot.Infrastructure.SmtpService". Unit tests don't make much sense here, but integration tests(Slow tests) do.
If "ComponentRoot.Infrastructure.Facade" is used directly it might be a DSL, else it could be a implementation for a given framework (HTTPModules and HTTP Handlers come to mind). This is the classic "Service Layer".
Anyone can extend the component with their own infrastructure, but the core logic is unmodifiable and rigorously tested.
No comments:
Post a Comment