Archive

Archive for the ‘Presentation’ Category

Many to Many Relationships with CodeFluent Entities

June 14, 2012 Leave a comment

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):

MyLibraryModel2

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:

view

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:

method

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:

result

Hooray, looks good Smile

 

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.

Cheers,

Carl Anderson

CodeFluent Entities: ASP.NET AJAX/JSON Producer sneak peek

June 8, 2012 1 comment

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 Smile

 

The homepage generated by default lists all namespaces and their contained entities:

04 - Result

 

Clicking on an entity gets you to the entity page:

05 - EntityPage

 

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:

image

 

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:

06 - Themes

 

Cheers,

Carl Anderson

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]
)
AS
SET NOCOUNT ON
SELECT DISTINCT [DiscountProduct].*, Product].* 
  FROM [DiscountProduct]
   INNER JOIN [Product] ON ([DiscountProduct].[Product_Id] = [Product].[Product_Id])
  WHERE ([DiscountProduct].[Product_Id] = @Id)

RETURN

Cheers,

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.

 

Cheers,

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.

image

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.

 

Cheers,

Carl Anderson

Follow

Get every new post delivered to your Inbox.

Join 52 other followers