As mentioned in the posts “The Starter Wizard” and “New CodeFluent Entities Milestone”, the Modeler provides a wizard creating the structure of your solution as well as configuring your producers so they point to the freshly created projects.
Among the wizard pages, there’s a page allowing you to select a model template from which you want to start:
Models displayed in this page are the default official ones (blank, and sample ones), but just as you can add your custom producers or custom rules to the Modeler, you can add your custom models to his screen as well.
First you need to locate the custom configuration. You’ll find this information by:
- opening Visual Studio,
- go to “Tools > Options… > CodeFluent Entities”,
- and select the advanced view using the advanced button at the top of the property grid.
As you’ll see, there’s a property named “Custom Configuration File Path” which points to a Custom.config file:
Open this file (or create it if necessary) and add the following XML content to it:
<codeFluent.Modeler> <starterWizardModelDescriptors> <starterWizardModelDescriptor name="Test" fileName="Test.cfxproj" description=”A custom model.” /> </starterWizardModelDescriptors> </codeFluent.Modeler>
This indicates the Starter Wizard to display a model named “Test”, corresponding to the “Test.cfxproj” project, in the “Select your model” wizard page.
Note: the cfxproj file should be placed in CodeFluent Entities’ Visual Studio templates folder which is “C:\Program Files (x86)\SoftFluent\CodeFluent\VSTemplates\Projects”).
Save the file, open your wizard, here’s what you should see now:
And voilà: our custom model project is now proposed in the wizard!
CodeFluent Entities provides “Methods” which allows developers to define custom data accessing methods (load, loadone, delete, count, search) which persistence producers will translate into stored procedures.
For instance, the following method:
Will generate the following stored procedure:
CREATE PROCEDURE [dbo].[Setting_LoadByName]
@Name [nvarchar] (256)
SET NOCOUNT ON
SELECT DISTINCT [Setting].[Setting_Id], [Setting].[Setting_Name], [Setting].[Setting_Value] FROM [Setting]
WHERE ([Setting].[Setting_Name] = @Name)
You can also create what we call Raw methods which are platform specific code such as T-SQL or PL-SQL, but you can also mix both, that is to say create a CFQL method so upper layers benefit from the out-of-the-box features provided by such methods and just override the actual body of the stored procedure.
For instance say you wanted to create a topped method which the number of returned rows can be passed to the method. The “TOP” statement doesn’t exist in CFQL (see TOP in CFQL for more information) so a way to do this would be to mix CFQL and T-SQL for instance.
To do so, start by defining your CFQL body:
And then define the Raw Text property of the body (select your method, and click on the “Bodies” property in the property grid):
Once this is done, if you build your model, the stored procedure quoted hereunder will be generated, and in upper layers your method will look just as expected (returning a SettingCollection, mapping returned columns to properties, and taking an int maxCount parameter):
CREATE PROCEDURE [dbo].[Setting_BoundedLoadAll]
SET NOCOUNT ON
SELECT TOP(@maxCount) * from Setting
Following the CodeFluent Entities Webcast post, an increasing number of you asked for the PowerPoint presentation used in the webinar: so here it is!
Last week we hosted a live webcast – which by the way was recorded and is available here – and following it we had several questions regarding the demo where we created a model from the Northwind database, and especially on how the tool deduced the relationships between entities.
The CodeFluent Entities importer detects foreign keys and transforms them into model relations, so we’re sorry to disappoint so many of you but there is absolutely no magic here!
The importer in fact relies on a database abstraction layer that presents a common interface for all supported databases or modeling systems that can be imported.
Here is a screenshot demonstrating how this intermediary abstraction layer « sees » an « old » Northwind Access Database, prior being imported, in a tool we call « Model and Database Explorer ».
Here you see two foreign keys that will be transformed into relations between entities if this database is imported as a model.
Now, back to magic! Even if there are no foreign keys on tables, the importer is truly capable of casting some voodoo spells
There is a parameter to the importer which is highlighted here:
When this parameter is set to true (the default value), the importer will try to determine automatically relations using column names. For example, say you have two tables like these:
If no foreign key is declared, the importer will « guess » if this is a 1:M or 0:M relation.