Structuring Projects for Team Foundation Server

My team spent some time this past week evaluating various approaches and lessons learned from various projects  We boiled it down to something that seems to be working well, and distills what’s worked for some teams.  With the caveat that we’re still evaluating, here’s what we learned …

Solution
Local File System

C:\MyApp
	\MyApp.sln
	\Source
		\MyAppWeb
		\ClassLibrary1

Source Control (Team Foundation Server)

/Main
	/Build
	/Docs
	/Source
		/MyApp
			MyApp.sln
			/Source
				/MyAppWeb
				/ClassLibrary1
			/UnitTests
				/MyAppWebTests
				/ClassLibrary1Tests
	/Tests

Key points
Here’s a few highlights about this approach:

• On the client side, we explicitly creat our solution file up front instead of rely on defaults
• The project folder containts one master solution.
• The project has source and unit tests.  Loading the solution for the project, loads the source and unit tests
• The Main folder in TFS holds the project assets (Build, Docs, Source, Tests).  Using Main lets us create other folders for potential branches (Development, Production, Maintenance … etc.)

Repro Steps
Here’s a brief walkthrough to test using a file-based Web:

1. Create a blank solution in VSTS
2. Create a source folder on the file system (C:\MyApp\Source)
3. Add new Web project (C:\MyApp\Source\MyAppWeb)
4. Add new Class Library (C:\MyApp\Source\ClassLibrary1)

Verify your folder structure on your File System:

C:\MyApp
	\MyApp.sln
	\Source
		\MyAppWeb
		\ClassLibrary1

Adding to TFS

1. Add your solution to source control
2. Create a Main folder
3. Create a Source folder beneath Main

Verify your folder structure in Source Control Explorer

/Main
	/Source
		/MyApp
			/MyApp.sln
			/Source
				/MyAppWeb
				/ClassLibrary1

More Information
You should know that while I talked through the single solution scenario, there are additional patterns.  Here’s the key patterns we see:

1. Single solution
2. Partitioned single solution
3. Multi-solution

TFS Best Practices

The Microsoft Patterns and Practices team, in concert with the TFS team and a panel of customer reviewer has just released a terrific document on TFS Best Practices.  This is distinct from the TFS help on MSDN in the sense that it is not “How-to” guidance but is conceptual information and recommendations for how to use TFS to fit your development process

Design Pattern

Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.

The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral. Here you will find information on these important patterns.

To give you a head start, the C# source code is provided in 2 forms: ‘structural’ and ‘real-world’. Structural code uses type names as defined in the pattern definition and UML diagrams. Real-world code provides real-world programming situations where you may use these patterns.

A third form, ‘.NET optimized’ demonstrates design patterns that exploit built-in .NET 4.0 features, such as, generics, attributes, delegates, object and collection initializers, automatic properties, and reflection. These and much more are available in our Design Pattern Framework 4.0^TM. See ourSingleton page for a .NET 4.0 Optimized code sample.

Creational Patterns
Abstract Factory	Creates an instance of several families of classes
Builder	Separates object construction from its representation
Factory Method	Creates an instance of several derived classes
Prototype	A fully initialized instance to be copied or cloned
Singleton	A class of which only a single instance can exist

Structural Patterns
Adapter	Match interfaces of different classes
Bridge	Separates an object’s interface from its implementation
Composite	A tree structure of simple and composite objects
Decorator	Add responsibilities to objects dynamically
Facade	A single class that represents an entire subsystem
Flyweight	A fine-grained instance used for efficient sharing
Proxy	An object representing another object

Behavioral Patterns
Chain of Resp.	A way of passing a request between a chain of objects
Command	Encapsulate a command request as an object
Interpreter	A way to include language elements in a program
Iterator	Sequentially access the elements of a collection
Mediator	Defines simplified communication between classes
Memento	Capture and restore an object’s internal state
Observer	A way of notifying change to a number of classes
State	Alter an object’s behavior when its state changes
Strategy	Encapsulates an algorithm inside a class
Template Method	Defer the exact steps of an algorithm to a subclass
Visitor	Defines a new operation to a class without change

Design Patters and SOLID Principes

 

For those who are not aware of this, SOLID is an acronym for the first 5 principles of object-oriented design:

1. SRP The Single Responsibility Principle: — a class should have one, and only one, reason to change.
2. OCP The Open Closed Principle: — you should be able to extend a class’s behavior, without modifying it.
3. LSP The Liskov Substitution Principle: — derived classes must be substitutable for their base classes.
4. ISP The Interface Segregation Principle: — make fine grained interfaces that are client specific.
5. DIP The Dependency Inversion Principle — depend on abstractions not on concrete implementations.

You’ll find a fair amount of information on the web on these principles.

It seems to me that you need a good grasp of the SOLID principles before you’re ready to tackle Design Patterns (in more of an Architect role).  At least that is how my educational & career process evolved. Does anyone have other experiences or opinions?

I am curious to hear how other .NET developers learn and internalize Design Patterns.