The CodeFluent Entities Blog

CodeFluent Entities has a Store concept which you can use to sort entities of your model. A model can have several stores and your entities can be defined to be in a specific store.

Say you have an application storing referential entities in a specific database which might be used in the future by several other applications, as well as other entities that are specific to your application. Using the store concept is a way for you to separate define entities to be in one store , the one corresponding to your application for instance, and other entities to be in another, say the referential one for instance.

Then you can define several persistence producers in your project and assign each of them a specific store. As a consequence they’ll generate the code corresponding to their assigned store, and each producer can have a different connection string so these stores can actually be in different databases.

<cf:store name=”Referential” />
<cf:producer name=”SQL Server” typeName=”CodeFluent.Producers.SqlServer.SqlServerProducer, CodeFluent.Producers.SqlServer”>
<cf:configuration targetDirectory=”..\Persistence\Referential” storeName=”Referential”  />
</cf:producer>
<cf:producer name=”SQL Server” typeName=”CodeFluent.Producers.SqlServer.SqlServerProducer, CodeFluent.Producers.SqlServer”>
<cf:configuration targetDirectory=”..\Persistence\Advertising” storeName=”SoftFluent.Advertising”  />
</cf:producer>

Note: as of today (build 622) the Modeler doesn’t provide a “Store Name” property in the producer’s configuration property grid, however this will be available in the next version, in the advanced view.

Another point of interest is that by default, CodeFluent Entities doesn’t allow relations across different stores as entities can be in different databases, on potentially different servers (and even in different storage systems!), so stores might not be able to communicate with one another.

However if ever in practice stores are on the same server, and in the same database you can decide to override this behavior and this can be done by setting the allowCrossStoreRelations property on the project to true.

If it’s not your case, you know that stores should be on different servers in different servers, one could argue that at this point (separate producers and no cross-store relations) you might as well have one model for each store.
This is true in some scenarios, however, having all entities in the same model has its benefits such as centralizing all used business concepts, being able to define aspects and producers working on all entities at the same time.

In the end, it’s all up to you!