As discussed in the “What is a CodeFluent Entities model?” post, CodeFluent Entities projects contain:
- surfaces, which are graphic views of your model,
- XML parts, which are storage units.
By default, when creating a new project, you have a single surface named “Default” and a single model part named <DefaultNamespace>.cfp which will both contain all your entities:
In the screenshot above you can tell that I have several namespaces, let’s say I want to chunk my model up, so I have one surface per namespace in addition to my default surface. Select the Surfaces folder, and create a new one, you’ll see that a dialog pops-up letting you choose which concepts you want to import:
Here’s the result after repeating this logic for each of my namespaces, isn’t it a lot more readable?!
Yet, all entities are still stored in the same, unique, model part “AdventureWorksReloaded.cfp”, making it hard to work collaboratively (doing edits on any of my surfaces would automatically check-out the AdventureWorksReloaded part as all entities are stored in this one).
This again can be changed: select a namespace and from the property grid, switch the default part to a new part.
If I do this for all my namespaces, in the end my main part will just contain project level settings, producers and import other parts:
Organizing my CodeFluent Entities project this way, each developer can be in charge of a functional namespace and work in his scope without stepping on someone else’s shoes.
Finally, you could even go one step further by enabling the “Create One Part Per Type” option which creates one part per entity or enumeration:
Not only is this a very handy option when collaborating on the same source-controlled model, but you can also get great performances on big models as it avoids to have one big XML file containing all your project.
Hope this helps,
Starting a few weeks ago, old timers might have noticed that CodeFluent Entities is now shipped as a single MSI and not as a zip containing two MSIs (and a readme) anymore.
CodeFluent Entities Editions
CodeFluent Entities exists in what we call two editions which both have their own installer:
- CodeFluent Entities Core Edition: the meta-compiler, what actually builds the stuff
- CodeFluent Entities Modeler Edition: the graphic interface, a Visual Studio extension wrapping the meta-compiler.
The Modeler Edition includes the Core Edition: it’s a Visual Studio Extension (for VS 2008 SP1 and upper) providing a user interface to the Core Edition. This was one of the two MSIs that were shipped and it’s now the only MSI that is retrieved when downloading the product.
So even though you only have a single MSI, you can still use CodeFluent Entities without the Modeler, just using XML files and CodeFluent.Build.exe in command line, as you used to using the Core Edition.
Ok, so from now on the “Core Edition-only” installer isn’t available by default anymore, but still, my development team needs it, what can I do?
If for some reason you still need the “Core Edition-only” installation MSI, please contact our support (support ‘at’ softfluent ‘dot’ com) as they can provide you with this installer.
Visual Studio 2012 RC is now available with its user interface updates and so is CodeFluent Entities
From now on, CodeFluent Entities includes three styles by default:
- Class Designer Style,
- Blend Style,
- the new Metro Style
Here’s a screenshot of this new Metro Style in Visual Studio 2012 RC:
Same style in Visual Studio 2010:
What I really like about this new Metro Style is that it uses vector icons, making your model look a lot nicer when you zoom in closely:
Close-up using the Class Designer Style:
Close-up using the Metro Style:
From the “Solution Explorer”, doing a right-click on the “Surfaces” folder and selecting “Surface Rendering Configuration”, you can select one of the other provided styles or even create your own:
Hope you like it,
Yesterday, Scott Allen posted on his OdeToCode.com blog a very interesting blog post named Many to Many Relationships with EF illustrating how to setup a many to many relationship with EF Code First and then, and it’s the interesting part to us, how to use the SelectMany operator to “flatten” a sequence of book authors.
In fact, we thought it was so interesting that we decided to post a little something showing how to do it in a model-first way, using CodeFluent Entities. The result is the same, yet the way to do it is quite different.
Developing the Sample
Unlike EF Code First, CodeFluent Entities is model-first, therefore it all starts by creating a model.
Here’s our model (btw here’s a little preview of our soon-to-come vector-based & metro style theme):
Code generators (named producers in the product) will translate this platform independent model into actual code. So the SQL Server producer will translate the Book and Author entities into tables, their properties into columns, since a many to many relationship is declared between the Book and Author entities, an association table will also be created.
Another nice feature which you can see in the screenshot above is that you can add what we call “instances” to your entities which will be translated by actual lines of data. It’s a convenient way to initialize your generated database with data.
Now that we have our database and data, let’s write our method which will load all this data in a flat view.
Using CodeFluent Entities you can create actual SQL views and that’s precisely what we did:
Note: see the “Auto infer lightweight entitiy” checkbox on the upper right? Checking this will generate a dedicated .NET class mapped to your view ;) See here for more info.
We created a view named “FlatView” which selects book ids, titles and author names. Here’s what it generates:
CREATE VIEW [dbo].[vBooksFlatView] AS SELECT [Books].[Id], [Authors].[Name], [Books].[Title] FROM [Books] LEFT OUTER JOIN [Authors_Books_Books_Authors] ON ([Books].[Id] = [Authors_Books_Books_Authors].[Id2]) LEFT OUTER JOIN [Authors] ON ([Authors_Books_Books_Authors].[Id] = [Authors].[Id]) GO
Now that we have our view, we created method which loads from this view:
Methods are once again platform independent and will be translated in regular methods by a .NET producer or into stored procedures by a persistence producer. Here’s what the SQL Server producer generates:
CREATE PROCEDURE [dbo].[Books_LoadFromFlatView] AS SELECT [vBooksFlatView].[Id], [vBooksFlatView].[Name], [vBooksFlatView].[Title] FROM [vBooksFlatView] RETURN
Now let’s run side by side EF’s dynamically generated query (on the left) and CodeFluent Entities’ static one (on the right) to compare results:
Hooray, looks good
Points of Interest
Many to many relationships are easy to setup: create two properties, hold shift+click and make them point to one another, set its cardinality, and you’ve got your relation! Association tables and all related code will automatically be generated.
Initialize your generated database with data: specify instances to get test data or default data.
No dynamic code: CodeFluent Entities generates stored procedures, views and etc. No dynamic code is used to so you can easily debug and predict what’s going to happen at runtime.
Platform Independent: all this logic is outside of your code, it documents your application and provides a clear picture of what the application does and how it does it. Furthermore, you can add producers to translate this model to other technologies: want to go from C# to VB.NET? Push a button. Support Oracle Database or generate WCF Services? Add a producer.
In the previous post we’ve seen how to generate in a few minutes an ASP.NET AJAX/JSON web site using the brand new producer (watch-out it’s pre-release software!), well here’s a sneak peek of what gets generated
The homepage generated by default lists all namespaces and their contained entities:
Clicking on an entity gets you to the entity page:
On the entity page you’ll find a screenshot of the entity from which this page was generated. On the left side of the page you’ll find a list of actions available on this entity which correspond in fact to business methods provided by the entity:
The generated web site uses jQuery to contact JSON web services to retrieve the data, and jQuery UI and jqGrid to display it. By the way, you’ll notice the generated web site supports jQuery UI themes out-of-the-box: