Archive for April, 2012

Designing Databases with CodeFluent Entities: Inheritance

April 20, 2012 Leave a comment

CodeFluent Entities tries to reduce the impedance mismatch between relational worlds and object-oriented worlds as much as possible and a good example of this I guess is how CodeFluent Entities supports inheritance across layers of your application.

Using CodeFluent Entities, an entity hierarchy defined in your model will be translated following the Table-Per-Type pattern in the persistence layer, when, in the generated business object model, this will be a regular class inheritance.

For instance, say we have the following hierarchy:

Here’s the result in the database:

Furthermore, data access methods will be modified accordingly to load the objects as expected in .NET. For instance, here’s the “Load” stored procedure that is automatically generated for the DiscountProduct entity:

CREATE PROCEDURE [dbo].[DiscountProduct_Load]
@Id [uniqueidentifier]
SELECT DISTINCT [DiscountProduct].*, Product].* 
  FROM [DiscountProduct]
   INNER JOIN [Product] ON ([DiscountProduct].[Product_Id] = [Product].[Product_Id])
  WHERE ([DiscountProduct].[Product_Id] = @Id)



Carl Anderson

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

April 11th 2012 Links: VB6, .NET Portable Class Libraries, Internet Explorer 10, ASP.NET MVC 4, eBooks

April 11, 2012 Leave a comment

Following the steps of Scott Guthrie’s link-listing series, here’s our new batch of links in our own series:



Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, and Windows 8

Good news for those still using VB 6: it’ll be supported on Windows 8!


It’s the end of mainstream support for Windows Vista

April 10, 2012: That’s the date Windows Vista support moves from mainstream to extended (meaning paid for everything but security updates).


Visual Studio

Hidden Gems in Visual Studio 11 Beta – .NET Portable Class Libraries

Scott Hanselman details Portable Class Libraries which is a feature available in Visual Studio 2010 (through an extension) and in Visual Studio 11.


TFS 11 Power Tools Beta Available

Good news TFS 11 power tools (beta) are now publicly available Smile 



ASP.NET MVC 4 now open source

Yay! All sources are on CodePlex! if you haven’t already, go check them out because that’s some good looking .NET code Smile


The Danger of the Large Object Heap (LOH)

Another article which we like on the same subject is: “Large Object Heap Uncovered” (written by Maoni Stephens).

We actually wrote an article ourselves which is quite related to the subject as well: Manipulating SQL Blobs With Streams.


IndexedDB Updates for IE10 and Metro style apps

IndexedDB is a W3C Working Draft that enables you to store, search, and retrieve data on the user’s device, even when Internet connectivity is disabled.  IndexedDB is a feature of the Web platform shared by IE10 and Metro style apps in the Windows 8 Consumer Preview.”

Hmm, very interesting…



Grab a free copy of “Under the hood of .NET Memory Management”

We did it, it was worthy, so we thought we’d share Winking smile


Free ebook: Introducing Microsoft SQL Server 2012

With SQL Server 2012 now available, I’m sure it’ll come in handy.



Carl Anderson

CodeFluent Entities: Basic Tips To Lower Generation Time

April 10, 2012 Leave a comment

First let’s start with some metrics. For this post I created 4 models:

  • Sample10 containing 10 entities of 10 properties,
  • Sample100 containing 100 entities of 10 properties,
  • Sample300 containing 300 entities of 10 properties,
  • Sample500 containing 500 entities of 10 properties



Screenshot of the Sample500 default surface


Furthermore, each model has the same two producers configured:

  • The SQL Server Producer,
  • And the Business Object Model Producer.

Note: A producer is a code generator translating the platform independent model you designed into scripts (e.g. T-SQL, PL/SQL), code (e.g. C#, VB.NET), services (e.g. ASMX, WCF) or UIs (e.g. SharePoint Web Parts, ASP.NET).

Finally, I’ve got a local SQL Server 2008 which my SQL Server targets and I’m generating the .NET Business Object Model in C#.

Now, keeping the default settings and generating each model from scratch using CodeFluent Entities (generate the persistence scripts, create the database, deploy them and generate the .NET API) takes:

  • 9 seconds for Sample10
  • 44 seconds for Sample100
  • 3 minutes 2 seconds for Sample300
  • 6 minutes 11 seconds for Sample500


Here are a few tips to lower generation time.


Set “Create Default Application” to “False”

By default, CodeFluent Entities infers a “virtual application” from your model: forms and grids will be created to display and edit each of your entities,  resources to display text, screens to call methods, etc.

Therefore, if you’re not generating the UI or are not currently working on it, disabling the creation of this default application will save you a whole lot of time.

To do this:

  • In the solution explorer select your CodeFluent Entities project,
  • and either from the property grid or from the project properties panel set the “Create Default Application” property to “False”.



Generate over again and the generation process should be much faster. For example:

  • Generating Sample300 drops to 2 minutes 10 seconds: we gained 52 seconds (28.5% gain)
  • Generating Sample500 drops to 2 minutes 51 seconds: we gained 3 minutes 20 seconds (53.9% gain)

Consequently, if not working on the generated UI or simply not using it, disabling this feature will save you a lot of time Winking smile


Disabling Producers You Are Not Using

Frequently when building your app, you’ll be doing just a little change here and there such as modifying a validation rule which only impacts the .NET class, or a method body which only impacts a stored procedure. In such cases, if your application is pretty big, a way to gain time is to disable unnecessary producers before generating over again.

For instance, if my change in the model only impacted .NET classes, let’s just disable the SQL Server Producer, so that I’m skipping the persistence layer update:


This will for sure save me some time.


Note: another point of interest is that CodeFluent Entities projects can have different producers enabled/disabled by configurations (see project properties, Build panel).


This way you could have several configurations (e.g. Persistence Dev, .NET Dev, UI Dev) with just the producers you need enabled in each one of them, and then switch from one another when needed.


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

SoftFluent MVP Program: Get a Free CodeFluent Entities Ultimate Edition!

April 6, 2012 Leave a comment