Sometimes the NHibernate designer may not be able to express the exact code or mapping that you want. For these situations the designer includes several “escape hatches” that you can use to insert your own code.
Suppressing Code Generation
You can prevent code from being generated for an entity by selecting the entity and changing its Generation setting to MappingOnly. This generates the mapping XML, but does not generate .NET properties: you can therefore provide your own property implementations in a partial class.
You can also prevent property generation at a per-property level. Properties also support a FieldOnly generation option: in this case, the designer will generate a private backing field for the property, but will not generate a wrapper property.
External Entity Definitions
In some cases the designer cannot express the mappings you need for an entity. In this case of course you can create and map the entity by hand without using the designer at all. But what if you need to create an association between a designer entity and a handwritten entity? In this case you can create a designer entity with the same name as your handwritten entity, but set its Generation option to None. The designer will emit neither code nor mapping for the entity, but the entity can still participate in associations.
Customising Mappings
You may encounter situations where you want to use the designer to define an entity, but there are one or two aspects of the mapping that the designer doesn’t support. To customise the mapping, implement the following partial method on the entity:
CopyC#static partial void CustomizeMappingDocument(XDocument mappingDocument)
The document provided to your implementation is the original mapping document created by the designer. You can use standard LINQ to XML methods to modify the mapping as required. For example, suppose you wanted to disable lazy fetching on the Widget class. The designer doesn’t provide an option to do this, but you can implement it by customising the mapping document:
CopyC#partial class Widget { private static readonly XNamespace MappingXmlns = XNamespace.Get("urn:nhibernate-mapping-2.2"); static partial void CustomizeMappingDocument(XDocument mappingDocument) { XElement classElement = mappingDocument.Root.Element(MappingXmlns + "class"); classElement.SetAttributeValue("lazy", false) } }
Using Alternative Mapping Representations
The designer abstracts away the detail of how mappings are represented in the generated code. As far as you are concerned, you specify the mappings visually in the designer, and the designer takes care of wiring up your entities.
However, if you want to control the way in which the designer performs that wiring up, for example to use Fluent NHibernate instead of XML, you can do so using a Code Generation Policy. To do this, go to the NHibernate Model Explorer (View, Other Windows, NHibernate Model), and open the Policies folder. If there is a Code Generation Policy shown, select it; otherwise, right-click the root and choose Add New Code Generation Policy. Then go to the Properties window and set the Mapping Representation option to the desired representation.
Generated Code File Layout
By default, the NHibernate Designer generates all code into a single file. Because the code is a generated artefact and you will not edit it yourself, you should not normally need to adjust this default. However, in some environments you may want to put each generated entity class in a separate file, for example to facilitate tracking changes in source control logs.
To do this, go to the NHibernate Model Explorer (View, Other Windows, NHibernate Model), and open the Policies folder. If there is a Code Generation Policy shown, select it; otherwise, right-click the root and choose Add New Code Generation Policy. Then go to the Properties window and set the Layout option to FilePerType.
