Multi-database architecture with CodeFluent Entities
In this article, we’ll see how to use multiple stores in your CodeFluent Entities application. In a previous post, we explained that the Modeler doesn’t provide a “Store Name” property in the producer’s configuration property grid. It’s now fully supported in the product so you don’t need to modify your XML parts by hand.
However, before we go any further, let’s bring some theory. The CodeFluent Entities “store” concept can be seen as a virtual storage unit and is mainly used by the persistence layer producers. Your CodeFluent Entities model contains by default one store which is always visible in your model, in the Visual Studio’s solution explorer tree view:
If you need to add a new Store, right-click on the “Stores” node and select “Add new Store”. Simply choose a name and your application now contains two stores: CarRental and CarRentalReferential.
Okay, great… but why would I want to do this?
When you develop an application, you may feel the need to dispatch your tables (inferred from model entities) in more than one database. For example, I want to create the Customer table in the CRM Database, and the Product table in the Master Data Database. Well, this is exactly why the store concept exists. Another example is shown here in this diagram:
Now, how to configure the “City”, “Address” and “Country” entities so their inferred tables will be generated to the CarRental database? It’s very easy : just select each of them, open the Properties window (F4), select the property grid Advanced tab (pointed by the red arrow below), and specify the target store like this:
Then you can define two persistence producers in your project and assign each of them a specific store:
Now don’t forget to configure your store and set it a specific connectionString. By building your model, CodeFluent Entities will generate the code corresponding to each store. The right things in the right places 😉 !
To conclude, I’d like to point out that, by design and by default, you can’t create model-level relationships between entities from different stores. Databases could be located in different servers or in different storage systems. But if you know what you’re doing, and still need this, you can change this default behavior by setting the allowCrossStoreRelations attribute on your project.