Archive for the ‘Presentation’ Category

Designing Databases with CodeFluent Entities: Names

April 19, 2012 Leave a comment

As explained in previous posts, CodeFluent Entities is way more that an ORM: you’re not just mapping classes to database objects, instead you’re creating a model which will be translated into stuff. Therefore if you add persistence producers such as SQL Server, Oracle Database or SQL Azure a database will be created or updated from it (see continuous generation from more info).

Creating a database implies naming a lot of stuff: tables, columns, constraints, stored procedures, etc., so I thought I’d give you a little details on how it works and how you can control this to create your own database.

First, CodeFluent Entities deduces names automatically from your model:

  • Table names are identical to entity names,
  • Columns are named “<EntityName>_<PropertyName>”,
  • Procedures are named “<EntityName>_<MethodName>”

Users can override this logic by:

  • defining a “Persistence Name” in the Property Grid on the object you want to change (entity, property, method, view, ..)
  • setting a “Persistence Property Name Format” at the project level to customize all property names of your project (e.g. replace the default “{0}_{1}” by “{1}” to remove the entity name prefix from all column names),
  • changing the naming convention

In practice a naming convention is a class implementing a naming convention rule which CodeFluent Entities will use to name persistence objects. Consequently changing the naming convention used will change the way all objects are named.

Several naming conventions are provided out-of-the-box and they all derive from one another, hence they benefit from the features of their parents. The hierarchy is as follows:

  • BaseNamingConvention (default)
    • FormatNamingConvention: modifies the name format of tables, columns, procedures, parameters, constraints.
      • LowerCaseNamingConvention: sets all database object names in lower case.
      • UpperCaseNamingConvention: sets all database object names in upper case.
      • DecamelizeNamingConvention: decamelizes all names (FirstName –> First_Name)
        • DecamelizeLowerCaseNamingConvention: all in lower case and decamelized (FirstName –> first_name)
        • DecamelizeUpperCaseNamingConvention: all in upper case and decamelized (FirstName –> FIRST_NAME)

Furthermore you can create your own custom naming convention by implementing the INamingConvention or by deriving from existing ones.



Carl Anderson

Get Started with CodeFluent Entities

April 18, 2012 Leave a comment

New to CodeFluent Entities? We’ve recently added a new page which might be or your interest:

CodeFluent Entities: Get Started

On this page you’ll find information and screenshots taking you step by step in the creation of your first CodeFluent Entities project may it be from scratch or using the starter wizard.

If you’d like to know more, but are not quite there yet, here are a couple pointers you might enjoy:

  • The product page: global presentation and screenshots of the product,
  • Features: feature list,
  • CodeFluent Entities: why? Examples!: a set of examples illustrating how CodeFluent Entities could benefit you,
  • Webcasts: a page containing a 20 minute overview of the product as well as a 1 hour product demo. Definitely a great place to see the product in action without spending too much time,
  • and of course the trial: when it comes to development tools, there’s nothing better than trying them yourself Smile


Hope this helps,

Carl Anderson

CodeFluent Entities: Standing Against Anemic Domain Models

April 6, 2012 Leave a comment

A few years ago Martin Fowler wrote this great post regarding what he calls “Anemic Domain Models”:

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.

That’s exactly what we try to avoid: those business logic empty classes, often wrapped in an extra layer of procedural services, which in the end just create a procedural style design. Furthermore, many people think that anemic objects are real objects, thus completely missing the point of what object oriented design is all about.


Instead, as Eric Evans states about the Domain Layer (or Model Layer):

Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

And we completely agree: especially right now, on the verge of a new technology wave (e.g. HTML5 & WinRT) the real key is your architecture. If you already have this rich domain layer, upper layers should just be consumers of it, empty shells providing user interaction to the heart of your business software. Consequently supporting a new platform (going from desktop to web, or Web Forms to MVC for instance) gets down to creating this new shell.

That’s what CodeFluent Entities is all about thanks to it’s .NET Business Object Model Producer: it generates a full .NET domain layer containing your business logic and which can be used across all .NET technologies (Windows Forms, WPF, SharePoint, ASP.NET MVC, ASP.NET Web Forms, Windows Workflows, etc.) this way securing your investments.

This is possible as this producer (= code generator) can generate:

  • Classes: plain old classes (not deriving from a base technical class), human readable, that are all partial and meant to be easily extensible by developers, implementing an extensive set of interfaces (ICloneable, IComparable, IDataErrorInfo, IEquatable, INotifyPropertyChanged, etc.) to ease development of upper layers, and easily debuggable as no code is dynamically generated at run time
  • Enumerations: since CodeFluent Entities is not an ORM, you can create your own .NET enumerations or reuse existing ones,
  • Multiple namespaces: as it’s common to have more than a single domain in real enterprise class applications,
  • Rules: to validate your data, set-up transactions, and implement your business logic,
  • Methods: create your own methods aside default generated ones,
  • light objects as structures or non-persistent objects useful to gather-up cross entity information,
  • components as a binary large object http handler to manipulate blobs in web environments, or a cache manager based on the standard ASP.NET cache manager, and more.

Last but not least, we don’t think that tools can generate entire enterprise-class applications, that’s not what we’re saying. Developing applications is a complex operation that needs more than data access and/or UI controls. Instead what we’re saying is that we provide a tool to developers which helps them set-up rock-solid foundations for their .NET applications, built on a consistent domain model, which developers will have to extend and fill-in the gaps.

The recipe we provide through CodeFluent Entities ends-up creating .NET applications based on a rich Domain Layer built by the tool and developers, containing the full business logic of your application. It’s a complete and consistent API which can be used on all platforms (x86, x64, desktop, web) across all technologies (.NET 2 to 4) this way securing your investments.

Carl Anderson

CodeFluent Entities: Build cross language and technology applications

April 4, 2012 Leave a comment

We’ve seen in the previous post (CodeFluent Entities Supports Multiple Database Systems) that once you invested the time into designing your application in CodeFluent Entities, you can switch from a database system to another by switching producers (e.g. Oracle Database to SQL Server, SQL Server to SQL Azure).

Well, the same logic also applies to upper tiers, for instance using the .NET Business Object Model Producer you can generate C# or VB.NET classes by selecting your desired target language:

Furthermore, the code generated by the .NET Business Object Model Producer supports all .NET Framework versions from 2.0 to 4.0 and runs on all .NET platforms: ASP.NET Web Forms, ASP.NET MVC, Windows Forms, WPF, Silverlight (2 to 4), SharePoint, Windows Workflow Foundation, WCF, etc.


In the end, CodeFluent Entities allows you to quickly build rock-solid foundations for your application whilst decoupling your business logic from the technology.



Carl Anderson

CodeFluent Entities Supports Multiple Database Systems

April 3, 2012 Leave a comment

Persistence producers translate your platform independent model into scripts and deploy them on the specified database to create your persistence layer.

Furthermore the persistence layer used is independent from the upper layers (.NET classes, services, user interfaces): switching your persistence layer does not change upper layers.

Therefore, using CodeFluent Entities allows you to create very flexible apps where switching or supporting a new database system comes down to switch or add producers:



Carl Anderson

Entity Framework and CodeFluent Entities

April 2, 2012 Leave a comment

One question that we get a lot is:

What’s the difference between CodeFluent Entities and Entity Framework?


How is CodeFluent Entities any different from Entity Framework?

In a nutshell, the ADO.NET Entity Framework is a data access method (it’s an ORM) which allows you to generate .NET classes mapped on to a database. On the other hand, and as explained in the “CodeFluent Entities is not an ORM post, CodeFluent Entities allows you to generate continuously components (from a model and not a database) such as scripts (e.g. T-SQL, PL/SQL), code (e.g. C#, VB.NET), web services (e.g. WCF) and UIs (e.g. ASP.NET, SharePoint).

Since we get this question a lot, we recently published an updated version of the “CodeFluent Entities & Entity Framework” document!

CodeFluent Entities & Entity Framework Download “CodeFluent Entities & Entity Framework” here (PDF)!

Furthermore, if you want to see CodeFluent Entities in action so you can make your own opinion, there’s the latest recorded live product demo which is available on our YouTube channel.Likewise, on April 13th we’ll be doing a 20-minute “CodeFluent Entities Tour” for DevProConnections so if you’re not familiar with the product and are looking for a quick way to know more this is definitely a great option for you.

Finally, and to me there are no better way, you can try the product yourself and see how it’s different from Entity Framework. To do this, SoftFluent provides a free version which is available online: check-out the Personal Edition.


Carl Anderson

What’s CodeFluent Query Language?

March 30, 2012 Leave a comment

CodeFluent Query Language (a.k.a. CFQL) allows you to write platform independent data accessing queries which producers (producer = code generator) will translate into optimized stored procedures.

For instance you can define the following CFQL query in your model:

<cf:method name="LoadByName" body="load(Name) where Name startswith @Name"/> 

The SQL Server Producer will generate the following stored procedure:

CREATE PROCEDURE [dbo].[Test_LoadByName] 
@Name [nvarchar] (256) 
SELECT DISTINCT [Test].[Test_Id], [Test].[Test_Name] 
    FROM [Test] 
    WHERE ([Test].[Test_Name] LIKE (@Name + '%'))


And the Oracle Database Producer will generate the following equivalent:

        "#Name" NVARCHAR2) AS 
    V_CF_CURSOR "Sample"."CF_#Runtime".CF_CURSOR_TYPE; 
        SELECT "Test"."Test_Id", "Test"."Test_Name" 
            FROM "Sample"."Test" 
            WHERE ("Test"."Test_Name" LIKE ("#Name" || N'%')); 

As you can see data accessing queries are not built in-memory dynamically at run time but instead a classic stored procedure is generated at development time.

As a consequence developers can:

  • see what’s going to happen at run time and avoid bad surprises (like this one when using EF for instance),
  • debug it easily if they need to,
  • change the code if the need to.


Carl Anderson

CodeFluent Entities: Initializing your application with data

March 26, 2012 Leave a comment

In our previous posts, we’ve seen that from a single platform independent model (see CodeFluent Entities is not an ORM) you can generate continuously (see Continuous Generation) complete databases, .NET classes, web services or UIs.

That’s great but when you’re developing your application, this will all be empty and just like an empty party, an empty app is no fun Smile

Well using CodeFluent Entities, from Visual Studio, you can specify “instances of data” in your model. What’s great about instances is that persistence producers such as the SQL Server producer, Oracle Database producer or SQL Azure producer, will translate those into a SQL script which will insert/update data in your app!

Here’s an example:

Select an entity and click on “Add Instance” to add instances one by one using the instance dialog.

You can also use the instance grid (accessible from the ribbon, in the “Batch Modeling” group) to multiple instances at a time in a grid:


For the newcomers, we published a while ago a 1 minute video illustrating how to generate code and data using CodeFluent Entities, plus using the generated code right away in the following post: How to generate with data (video)


Carl Anderson

CodeFluent Entities: Continuous Generation

March 21, 2012 1 comment

In the previous post, CodeFluent Entities is not an ORM, I briefly talked on how CodeFluent Entities is different from an ORM as your not mapping a database to an object model but instead your defining a model from which you’ll generate stuff depending on the code generators (a.k.a. “producers”) you specified in your project.

Therefore CodeFluent Entities is a very DRY product as from a single model you’ll update consistently your database, classes, services, UIs, and so on. However, as we developers know, there’s absolutely no way you’re going to model your entire application the right way on the first shot: specs move along, we always forget something or just did not think of a particular scenario…

As a consequence such a product would be useless without continuous generation. By continuous generation I mean that you can go back to the model do some changes in it and generate over to update consistently all your layers without losing changes nor data!


Everything starts from the database where CodeFluent Entities’ differential engine enables hassle-free schema updates without losing any data.

Say you have an existing Customer entity:

From which you generated a Customer table containing data:

Adding a new Name property to the entity:

And generating over will preserve our existing data:

Last but not least, please note that things like up-casting, adding/removing constraints or relations are fully supported so you can generate continuously throughout your developments.



Carl Anderson

CodeFluent Entities is not an ORM

March 20, 2012 1 comment

CodeFluent Entities is a unique product integrated into Visual Studio 2008/2010/vNext which allows you to generate components such as scripts (e.g. T-SQL, PL/SQL), code (e.g. C#, VB), web services (e.g. WCF, ASMX) and UIs (e.g. ASP.NET, SharePoint, WPF).

The code generation process is model-first and continuous: from your declarative model, a meta-model will be inferred which code generators will then translate into code. Over 20 code generators (a.k.a. “producers”) are provided “out of the box” and can be combined to create your own application following your desired architecture, using your desired technologies.

For instance, adding an instance of the SQL Server Producer to your project will translate your model into a database (schemas, tables, stored procedures, views, constraints, etc.):

Adding an instance of the Business Object Model Producer will translate your model into .NET classes (C# or VB.NET) consuming the persistence layer:

Adding a WCF Producer will generate WCF services, contracts and proxies exposing your .NET classes:

Adding a WPF Smart Client Producer will generate a WPF application consuming the WCF services thanks to the generated proxy:

And that’s just an example of what you can do: you can also build ASP.NET web sites, SharePoint apps, Windows Forms apps, Silverlight apps, etc.

Your application is layered following best practices, all its business logic is in the middle-tier (the Business Object Model generated by the Business Object Model producer), and supporting a new technology gets down to adding a new producer or creating screens on the generated code.

Last but not least, you can create your own producer which translates this inferred meta-model into what you need.



Carl Anderson


Get every new post delivered to your Inbox.

Join 49 other followers