CodeFluent Entities is a software engineering product aiming to industrialize the production of enterprise-class applications on the .NET platform. As seen in the Architect Guide, this can be done by a business modeling step which will, thanks to a producer logic, generate fully functional components.
While the Architect Guide provides information to architects to design an application, the Developer Guide provides information on what was actually generated and how to use the generated code.
Whatever your final application is (desktop, web, SharePoint, etc.), using CodeFluent Entities you'll have a Business Object Model (BOM) which basically is an API containing all the logic of your application. This BOM should contain all of your business logic, and implements tons of interfaces and best practices to help you easily build your user interface (UI) and/or upper layers. The key point here, is that absolutely no business code should reside in the UI, and as a consequence, adding a new client to your application should limit to doing over your screens and no more.
With this in mind, we in fact recommend to extend the BOM as much as possible by completing the classes, rather than adding extra-layers and chunking your own logic above or aside, the goal being to avoid the “anemic domain model” syndrome.
In practice, as a developer what we recommend is to work in the model as much as possible. This way changes are applied application wide, in all layers and are completely decoupled from technology thanks to plaform independent concepts such as entities, properties, methods, etc. However, if this is not possible due to very specific business needs or technical reasons, then extend the BOM so those extension are available to all upper layers. The BOM is composed of plain old partial classes, consequently extending it is nothing more than standard .NET development as you already know.
Partial Classes
For small code chunks, the snippets can be added to the model: this ensures that generating from the model still generates code that compiles right away. A snippet is basically a code chunk which is pasted "as is" at a specified location in the output code. However, as you understood, this adds platform dependent code to your model and this method might not be convenient for consequent pieces of code
As we said here-before, all generated classes are partial classes, which means they can be extended in another file than the generated one. This way we avoid the eventuality of losing some changes throughout generations. This way the developer completely controls the content of the second file: he can extend the class as needed and desired.
The naming convention of those custom files is up to you. For instance common naming convention used for partial classes can be: MyClass.Partial.cs or MyClass.Custom.cs. Naming them this way ensures the class is placed next to the generated one, making it convenient to spot hand-made classes.
Production Target Path Format
Another way of implementing partial classes is to change production settings so that produced classes are produced differently in a particular filename and hand-made classes keep the standard name (e.g. MyClass.cs).
For instance, by specifying the productionTargetPathFormat attribute of the BOM Producer configuration node to {0}\{1}.g{2} will generate files named as MyClass.g.cs; this way developers can create MyClass.cs partial classes containing the extra members.
| Configuring the productionTargetPathFormat |  Copy Code |
|---|---|
<cf:producer name="BOM Producer" typeName="CodeFluent.Producers.CodeDom.CodeDomProducer, CodeFluent.Producers.CodeDom"> <cf:configuration productionTargetPathFormat="{0}\{1}.g{2}" outputName="{0}.dll" targetDirectory="..\Model" /> </cf:configuration> </cf:producer> |
|
 |
Note: Regarding the productionTargetPathFormat value: {0} corresponds to the target directory, {1} corresponds to the file name (without extension), {2} corresponds to the extension (e.g. ".cs") |