Archive for June, 2011

Create CodeFluent Models From Existing Databases And Models

June 30, 2011 3 comments

Using the importer, you can create a CodeFluent Entities model from an existing database or a model such as ADO.NET Entity Framework, or a UML one. Basically, instead of starting from scratch to design over your existing application, you can use the importer to parse your existing work and create your new model from what you already did. Then, since you have a brand new model, you can generate a brand new application using CodeFluent’s producers.

Supported databases are:

  • Microsoft SQL Server,
  • Microsoft SQL Server CE,
  • Microsoft Access,
  • Oracle Database,
  • Any OLE DB supporting the IDBSchemaRowset interface.

Regarding models, the supported ones are:

  • Enterprise Architect,
  • ADO.NET Entity Framework,
  • XMI

Here’s a video showing how to import an existing Access database (the Northwind one) into a CodeFluent Entities model:

Importing Northwind

CodeFluent Entities: A Model-Driven Software Factory

June 29, 2011 Leave a comment


Have you ever been in the same situation as Dilbert here-above? Sure you have, and that’s precisely what model-driven software developments address. In fact, a year ago, we released a white paper named “How Model-Driven Software Development can help your projects succeed” which among other subjects mentions this issue and how it can be addressed.

On a more pragmatic level, our product, CodeFluent Entities, is in fact a direct implementation of the former point and if you’re looking for a way to avoid situations like Dilbert’s you really should check-out this video which is a recording of our latest webinar and shows it all in action:

CodeFluent Entities Webinar – June 15th 2011

Generate WPF Smart-Clients using CodeFluent Entities (video)

June 29, 2011 4 comments

CodeFluent Entities ships a WPF Smart-Client Producer (beta) which allows developers to generate a WPF application using WCF to communicate with the server.

The following video shows the producer’s output, and the application you see running in it is a 100% generated (database, object model, WCF services, WCF proxy, as well as WPF screens).

WPF Smart-Client Producer

This demo is actually part of the webinar so if you want to know more on what is shown, I invite you to take a look at our last webinar:

Manipulating SQL Blobs With Streams

June 28, 2011 Leave a comment

Streams have always been difficult to understand and master in programming, and yet it is a key concept that should be assimilated by all developers that develop "scalable" applications and want to get rid of storing data on physical disk. Streaming lets you cut up a block of data into small chunks that will be sent to the remote endpoint.

As an example, streaming is strongly used in Video-On-Demand offerings where customers can start watching a movie (usually weighing around 750MB in a compressed format) without having to download it completely on his local hard-drive. In this scenario, the VOD server splits the movie file in small "chunks" of data and sends them to the customer’s media software.

From a programming perspective, you can think of a stream as a one-dimensional set of contiguous data, which has a beginning and an end, and where the cursor indicates the current position in the stream. The data contained in the stream may come from memory, a file, a TCP/IP socket and even a database.

The core operations on a stream are: read, write and seek. In the .NET Framework, a stream is represented by the Stream class, which forms the abstract class for all other streams. Two important points with streams is that they are mostly used in a "forward only" mode and the length of the underlying data are not known in advance. We must be aware of this last constraint and try to "play" with it rather than look for workarounds.

Read the full article here!

Generate Web Parts Using CodeFluent Entities (Video)

June 27, 2011 Leave a comment

We introduced in previous posts that CodeFluent Entities provides a SharePoint Web Part Producer which lets you generate SharePoint web parts from your model:

Since you’re familiar with the theory, check-out this video to see how the generated web parts looks like by default:

Generating SharePoint Web Parts

Note: CodeFluent Entities supports WSS 3.0, MOSS 2007, SharePoint Foundation 2010, and SharePoint 2010

Lightweight Entities, Views and Auto-Lightweight

June 23, 2011 1 comment

In the previous post we saw how to leverage CodeFluent Entities’ DataSet built-in feature to load a custom set of columns from database. That’s practical, but what’s even more practical is to have an actual strongly-typed class to which I can data bind my UI controls.

Going back to my model we’re going to add a lightweight entity. As the name suggests it’s a light entity: it’s not persistent, it has no CRUD methods (e.g. load, save, delete) nor properties by default, and it does not implement any interfaces other than the ICodeFluentLightEntity by default.

<Id typeName=”int” />
<Street />
<CityName />

<CityAddress lightweight=”true”>
<CityName />

Using the Business Object Model producer, my lightweight entity will result in a single class (no collection class will be generated) and only contains the declared properties – CityName in our case – and a ReadRecord method which knows how to fill an instance of the class from a System.Data.IDataReader.

Alright so all we  have to do is add a raw method – lightweight entities only support raw methods since no table equivalent gets generated– which retrieves our desired data:

<CityAddress lightweight=”true”>
<CityName persistentName=”Address_CityName” />
<cf:method name=”LoadAllCities” body=”load()raw”>
SELECT $Address::CityName$ FROM $Address$

As you can see, we also set persistentName attribute on the CityName property to match the Address.CityName property so the generated ReadRecord parses the result properly. Then in our application, we can now use the generated method:

List<CityAddress> addresses = CityAddress.LoadAllCities();
foreach (CityAddress address in addresses)
Console.WriteLine("Name: " + address.CityName);

Looks better than using DataSets as in this post right?

The last point I want to talk about is the autoLightweight attribute which you can define on a persistent view: doing so does automatically all what we did here! This time, instead of declaring a new lightweight entity, we’re going to define a view on our Address entity and a method using our view:

<Id typeName=”int” />
<Street />
<CityName />

<cf:view name=”AddressCityView” autoLightweight=”true”>
<CityName />

<cf:method name=”LoadCities” body=”load from AddressCityView” />

Now this will generate an AddressCityView lightweight, and add a LoadCities method in the AddressCollection class which returns a list of AddressCityView instances. Lets update the code of our application to use this new method:

List<AddressCityView> cities = AddressCollection.LoadCities();
foreach (AddressCityView city in cities)
Console.WriteLine("Name: " + city.CityName);

And voilà! Now I’ve got a strongly-typed object to which I’ll easily be able to data bind my UI, behind the scenes it uses a persistent view, and all that without coding a single line of code!! Neat isn’t it?!

DataSet Support in CodeFluent Entities

June 22, 2011 2 comments

Let’s say we have an Address entity such as:

<Id typeName=”int” />
<Street />
<City />

And for a very particular screen we only need to list all cities contained in this table and we don’t need to retrieve all columns of our Address table. It sounds like a nice scenario to add a custom method doing just a select on that column, but how can I model that using CodeFluent Entities?

Well to model that we’re going to leverage 3 features of CodeFluent Entities:

First we’re going to add our raw method to our Address entity:

<cf:method name=”LoadAllCities” body=”raw” returnTypeName=”System.Data.DataSet”>
SELECT $Address::City$ FROM $Address$

As you can see, instead of writing 100% raw T-SQL I’m using Target Name Transformation to retrieve persistence names, so that my custom method won’t be broken if we change our naming convention later on. Furthermore, we’re setting the returnTypeName of our method to the standard .NET type System.Data.DataSet so my method will be able to return pretty much all I want.

In the end my SQL Server Producer will generate the corresponding stored procedure, and the Business Object Model producer the corresponding C# method which calls the underlying stored procedure and fills in my dataset.

Finally in my .NET application all I have to do is:

DataSet ds = Address.LoadAllCities();
foreach (DataTable table in ds.Tables)
    foreach (DataRow row in table.Rows)
        Console.WriteLine("City: " + row[0]);

Now obviously using a DataSet to retrieve a simple column is a bit oversized, but it illustrates a way of modeling custom queries retrieving data from multiple tables and filling them up in a DataSet. By the way, another way to do it would be by using persistent Views but this will be for another day Smile