The Business Object Model (BOM) Overview

SoftFluent CodeModeler is a product integrated into Visual Studio 2017 and higher, also available as a standalone command line tool, which allows developers to generate components such as scripts (e.g. T-SQL, MySQL), code (e.g. C#), and other types of files.

The code generation process is model-first and continuous: from your declarative model, a meta-model will be inferred which code generators will then translate into code. Some code generators (a.k.a. “producers”) are provided “out of the box” and can be combined to create your own application following your desired architecture, using your desired technologies. 

While the Architect Guide provides information to architects on how to design an application, the Developer Guide provides information on what was generated and how to use the generated code.

Whatever your final application is (desktop, web, etc.), using CodeModeler, 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 your business logic and implements many standard .NET interfaces and best practices to help you easily build your user interface (UI) and/or upper layers. The key point here, is that no business code should reside in the UI, and therefore, 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 extending 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 platform-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.

The Business Object Model

The Business Object Model is a set of .NET classes, generated by the Business Object Model producer, constituting a Domain Model.

The generated model is a direct translation of your CodeModeler model; therefore, it contains all key concepts of your application. Consequently, a good practice is to also include in this same class library all hand-coded extra business rules, concepts and operations.

The Business Object Model (BOM) sits between the persistence layer and upper layers such as the UI and/or Services layer. Using the classes in the BOM will allow you to manipulate their corresponding persistence objects and all upper layers are based on this same BOM. Therefore, the generated BOM can be used across all .NET technologies (ASP.NET Web Forms, ASP.NET MVC, Windows Forms, WPF, etc.) and remains the same, independently of the underlying persistence layer (e.g. SQL Server, SQL Azure, MySQL, PostgreSQL, etc.).

Since it's the backbone of your application containing all its logic and reused by all layers, whenever a developer needs to extend it manually, he should always do it in the BOM layer.

The BOM is composed of classes, each class being the result of an entity created earlier, at design time. The properties that were designed will appear as properties of the generated classes, and the same principle is true for the designed methods. Therefore, if we designed a Customer entity for instance, our BOM will contain a Customer class, and each properties, methods, and designed rules will be contained in that class.

Each generated entity contains a default set of features.

Basically, each entity holds a default set of methods such as Load, Save, Delete, Validate, ergo CRUD operations and validation are supported out-of-the-box and without a single line of code. Of course, more methods (and features) are available than those four and they'll all be detailed in this section.

Added to those methods, the generated entity class and its corresponding collection class implement an extensive set of standard and expected .NET interfaces, helping the developer in his further developments. It's also important to emphasize that all generated classes are designed to ease the developer's further developments. For instance, all classes are serializable, related entities are lazy loaded, sorting and pagination methods are available and much more.

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.

Using the Business Object Model

At design time, you modeled your business application using business entities, each one of them having properties, and relations to one another. Once the business model is ready, you can generate your Business Object Model (BOM) thanks to the Business Object Model Producer.

By default, two classes are generated per entity: the first class corresponds to the entity class, and the other one to a collection of those entities. For instance, a Customer entity will generate a Customer class and a CustomerCollection class which can manipulate several Customer instances. Apart from that notion, the BOM will be organized exactly as designed in the model.

For instance, given the following model:

The Customer class will contain four properties: Id of type int, Name of type string, Address of type string, Orders of type OrderCollection.

Without any custom code, you then can load customers:

// Loads the customer with the id 42
var customer = Customer.Load(42);
 
// Loads all customers from database
var customers = Customer.LoadAll();

Save a customer:

var customer = new Customer();
customer.Name = "John Smith";
customer.Address = "744, Washington Street";
customer.Save();

Delete a customer:

var customer = Customer.Load(42); // or customer = new Customer{ Id = 42 }; to avoid loading it
customer.Delete();

The BOM is a direct implementation of the model, consequently it applies the structural rules defined by the model. From the model we understand that:

• a customer can have several orders,

• an order can have only one customer,

• an order can contain several products.

The generated BOM conforms to those structural rules, and we can navigate In the BOM:

var customer = customer.Load(42);
foreach (var order in customer.Orders)
{
        Console.WriteLine("Order #" + order.Id + " contains:");
        foreach (var product in order.Products)
        {
            Console.WriteLine(" + Product #" + product.Id + ": " + product.Label);
        }
}

As you can see relation properties are lazy loaded meaning that when getting the customer.Orders properties, if it's null, it's value will automatically be loaded from the database. Next times, as the property is non null, no extra round trip to the database will be done.

We can also create relations easily:

var customer = Customer.Load(42);
var product = product.Load(1);
 
var order = new Order();
order.Code = "ORD1";
order.Date = DateTime.Now;
order.Customer = customer;
order.Products.Add(product);
order.Save();