Flexbase Solution Structure
Let us look at the most interesting layer for the developer, which is the bridge layer.
What is a bridge layer? The bridge keeps the generated code and flexbase libraries decoupled.
After we have generated the code, if we want to implement or extend something In the classes which are generated, it becomes a little difficult. For that, we have created something called a bridge
Let's say we have the IFlexServiceBusBridge. It inherits from the IFlexServiceBus which helps to customize any of the methods which are not available with IFlexServiceBus also. Because after the code is generated it is difficult to override that. There might be some customization. This bridge layer helps to keep the code maintained as well as updating the Flex without disturbing the existing generated code. The customizations are always available.
There are some bridges available. We will go through the bridges as we look into individual modules in depth.
One of the interesting bridge is the DomainModelBridge. All the flex objects, which is used by the persistence layer inherits from the domain model. In the Domain model definition, we have some common fields created, and the default string length for ID is 32. What if someone wants to increase the ID length 50 or what if someone wants to create some fields which are common across all your domain model in their application? This helps us to override any of the values. We can have the ‘get’ and ‘protected’ set. Let’s say we want to increase the string length to 50. Across all domain model, it can be customized. This will be applicable across all the domain models that get created by the code gen. This is one of the examples. We have more bridges like this.
We have the FlexiFlowBridge. For queries also we have the bridge. If anybody has worked in the earlier version of Flex, we were generating code from flexi query. Now, instead of FlexiQuery, we will have a FlexiQueryBridge, FlexiQueryEnumerableBridge.
Bridge is the layer between your application code and the Flexbase libraries. We have different thing for the host.
Instead of the FlexCommand, we are going to use the FlexCommandBridge. We pass command in the bus, but in case there is a need to add some extra field for the Command, so instead of flex command we are inheriting from the FlexCommandBridge in the application code, so that it is easier to add comment fields in this bridge.
Similarly, we have the persistence. Instead of ‘IFlexRepository’, we have ‘IFlexRepositoryBridge’. We will see each one in-depth at a later stage.
One of the most interesting things that needs to be told is our ‘FlexHostContextInfo’. This is a very important concept to understand. if we want to summarize, this is a layer like any of the HTTP context data, viz. user ID, or the HTTP host info. Similarly, many of the information comes from the HTTP context pipeline. Those information needs to be used across the application, whether it's an insert update operation or a query. Its user ID is useful everywhere. We need that to be accessed. This context info captures that one and moves it across the entire application. We will also understand that when we get into the Crud operations