MSDN Magazine - February 2009 - (Page 42)

public SiteMap() { // Map the simple properties // The Site object has an Address property called PrimaryAddress // The code below sets up the mapping for the reference between // Site and the Address class References(s => s.PrimaryAddress).Cascade.All(); References(s => s.BillToAddress).Cascade.All(); References(s => s.ShipToAddress).Cascade.All(); } When you configure ORM tools, you generally have to: 1. Specify the table name to which an Entity class maps. 2. Specify the primary key field of an Entity and usually also specify some sort of strategy for assigning the primary key values. (Is it an auto number/database sequence? Or does the system assign the primary key values? Or do you use GUIDs for the primary key?) 3. Map object properties or fields to table columns. 4. When making a “to one” relationship from one object to another (such as the mapping from Site to Address), you need to specify the foreign key column that the ORM tool can use to join parent and child records. All of that is generally tedious work. It’s ceremony that you have to follow to get the ORM to persist objects. Fortunately, you can eliminate some of the tedium by embedding some Sensible Defaults in our code (note the presence of capital letters). You might notice in the mapping examples that I did not specify a table name, a primary key strategy, or any foreign key field names. In my team’s Fluent NHibernate mapping superclass, we set some defaults for our mapping: public abstract class DomainMap : ClassMap , IDomainMap where T : DomainEntity { protected DomainMap() { // For every DomainEntity class, use the Id property // as the Primary Key / Object Identifier // and use an Identity column in SQL Server, // or an Oracle Sequence UseIdentityForKey(x => x.Id, "id"); WithTable(typeof(T).Name); } } Opinionated Software You might notice that I described the adoption of conventions as “restrictive.” Part of the philosophy behind convention over configuration is to make “opinionated software” that creates artificial constraints on the design. An opinionated framework expects developers to do things in a certain way almost to the point of eliminating flexibility. Proponents of opinionated software feel that these constraints make development more efficient by removing decisions from the developers and promoting consistency. One opinion used by my team is that all domain model classes are completely identified by a single long property called Id: public virtual long Id { get; set; } In this code we are setting a policy that all classes that subclass DomainEntity will be identified by the Id property that is assigned with the identity strategy. The table name is assumed to be the same as the name of the class. Now, we can always override these choices on a per-class basis, but we’ve rarely had to do this (a class named User had to be mapped to a table named Users just to avoid a conflict with a reserved word in SQL Server). In the same way, Fluent NHibernate assumes a foreign key name based on the property name that references another class. Granted, this isn’t saving many lines of code per mapping class, but it makes the parts of the mapping that do vary easier to read by reducing the overall noise code in the mapping. Convention over Configuration It’s a simple rule, but it has had a number of profound impacts on design. Because all entity classes are identified in the same way, you have been able to use a single repository class instead of writing specialized repository classes for each top-level entity. In the same vein, URL handling in a Web application is consistent across entity classes without your having to register special routing rules for each entity. Following this opinion reduces the cost of infrastructure for adding a new entity type. The downside of this approach is that it would be very difficult to accommodate a natural key or even a composite key or to use a GUID for an object identifier. That’s not an issue for my team, but it could easily block another team from adopting our opinion. Now, how do you enforce these opinions? The first step is simply creating a common understanding and agreement within a team about these opinions. Informed developers stand the best chance of effectively using these opinionated design choices to their advantage. Likewise, convention over configuration can be a near disaster if the developers aren’t familiar with the existing conventions or the conventions are confusing. You might also consider using a static code analysis tool as part of your continuous integration build to automatically enforce your project’s conventions. 42 msdn magazine Software developers have sought to gain more productivity and make systems more dynamic by moving behavior out of imperative code and into declarative XML configuration. Many developers felt that the proliferation of XML configuration went too far and was becoming a harmful practice. The strategy of defaults over explicit configuration is also known as convention over configuration. Convention over configuration is a design philosophy and technique that seeks to apply defaults that can be implied from the structure of the code instead of requiring explicit code. The idea is to simplify development by allowing the developer to worry only about the unconventional parts of the application and architecture. Right now, many people are eagerly playing with the ASP.NET MVC Framework and experimenting with different ways to use it. In the MVC model of Web development there are a couple of sources of repetitive code that might be a great opportunity to apply conventions over configuration. Here are the five steps in the basic flow of a single request in the MVC model: 1. Receive a URL from the client. The routing subsystem will parse the URL and determine the name of the controller that handles this URL. 2. From the controller name determined by the routing subsystem, build or locate the proper controller object. 3. Invoke the correct controller method. Patterns in Practice

Table of Contents Feed for the Digital Edition of MSDN Magazine - February 2009

MSDN Magazine - February 2009 Contents Toolbox CLR Inside Out Data Points Cutting Edge Patterns In Practice Best Practices .Net Interop "Oslo" Basics Patterns Silverlight Under The Table Foundations Windows With C++ .NET Matters Going Places { End Bracket }

MSDN Magazine - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.