| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

ConventionOverConfiguration

This version was saved 15 years ago View current version     Page history
Saved by ferventcoder
on March 29, 2009 at 2:52:32 pm
 

Convention Over Configuration

 

How much time do we spend configuring frameworks (or anything for that matter) so we can use them?? Why does it take so long to go from getting a framework to it actually being useful?  There are all of these options I am required to set to even get up and going.  It makes for more powerful frameworks when there are a bunch of options, but it makes me think about the answers to all of those questions.

 

That's where conventions come in. Conventions are really like defaults.  Conventions really strive to give you what the framework believes is the default behavior.  When you subscribe to convention over configuration, it gives you the ability to allow the user of your framework to be up and using your framework fast!  And that's really what you want. If your customer has to read/think too much to use your framework, then it's very likely that they will go elsewhere or fall back into something more comfortable.

 

To be able to allow conventions, one must really address being an opinionated framework.  This makes it very easy to have a standard way of doing things as directed from the opinions of the framework. 

 

UppercuT uses conventions to help you get to what you want really fast, and that is writing code. It gets out of your way quickly, but it also is a very configurable framework to suit your particular needs. The configurability of UppercuT makes it a very powerful framework, but by default we hide it from you with conventions until you need it.

 

UppercuT Conventions

  • An automated build should be able to done locally as well as on a build server (Continuous Integration).
  • You are working in only one language in your solution.  By default that is C#. This is extremely easy to override and we give you access to that directly.
  • You will build your project using .NET 3.5. This is also easy to override. When you look in the Build.Settings.bat file you will see the options are below the convention. 
  • You want a project assembly file that will handle versioning for you.  To do this you just have to include the SolutionVersion.cs (.vb) file AS A LINK in each project and remove all duplicate items from each project's assembly.cs (.vb) file.
  • You use MbUnit to author your tests. You can change this to NUnit quite easily.
  • When working on tests you follow a specific convention of naming and separation to keep integrated tests separate from unit tests.  We have thought about ignoring certain categories.  See more here: http://ferventcoder.com/archive/2009/01/27/universal-nant-script-for-mbunit.aspx
  • You keep your references local to your project. You also keep them in a folder at the top level of your project called lib.  If you don't, you just need to point the Build.Settings.bat, Test.bat, and other .bat files to the location you are going to keep the references to NAnt and other libraries we use to build and test your project.
  • You want to run NCover and NDepend on your project to determine quality indicators.  This is easy to turn off.  Just find in the build.settings.bat file where we have pointers to their locations and set them to a path that doesn't exist.  One note about NDepend. Since we use the one that costs, we cannot include it in our framework. You will need to purchase that from NDepend and install it on any computer that will be doing the build. You may want to be sure you understand the licensing for NDepend.  If you want to run your own, you just create a custom task to call those analyzers.
  • You build your project in one directory (we do this automatically) and then you drop your code into another folder that can be used for deployments. This drop is known as packaging your code.
  • You have database scripts to run and you need to package those items. By default that is in a folder called db. You can easily change this to your database project folder name by editing the build.settings.bat file.
  • You use Subversion for source control. This is extremely easy to override using, you guessed it, the build.settings.bat file.
  • Your repository path is either a network path, something that uses a source control link (i.e. svn:// git://), or a URL.
  • You keep your solution in the top level directory.
  • You put the build.bat file at the top level directory so that you can easily create a standard for your continuous integration server to call that one file.
  • Right now we have uppercut using CruiseControl.NET to apply the build number to the assembly version.  At some point we hope to add support for TeamCity and other CI frameworks.

 

 

Comments (0)

You don't have permission to comment on this page.