Archive

Archive for the ‘.NET Domain Model’ Category

Using the Cache Sub-Producer

April 24, 2013 Leave a comment

 
CodeFluent Entities provides an integrated cache system for the Business Object Model (BOM) layer.  The Object Model Cache (OMC) is not enabled by default. To add the cache feature to your BOM you need to first add a Cache sub producer.
 

The Cache Sub-Producer

The Cache Sub-Producer


 
If you set the “Is Default Enable” attribute to “True” the cache feature will be enabled for all the entities in your model. You can also decide to enable or not the cache feature by entity or by method.
 
Enable Cache on an Entity

Enable Cache on an Entity


 
As you can see in the image above, you can independently specify whether you want to enable the cache feature for Collections or not by changing the value of the “Is Collection Enabled” attribute.
 
If you enable the cache feature, when calling a “LoadXXX” method (ex. Load, LoadById…) on your entity will make that a cache verification is performed before trying to load the data from the data source (SQL server for example).
 
If you want to bypass the cache you can call the “NoCacheLoadXXX” method (ex. NoCacheLoad, NoCacheLoadById…). When saving or deleting an instance of an entity, the cache is cleared (for that entity) and you can clear manually the cache calling the “CacheClear” method on an entity (public static method).
 
You may considerate some points when using a Cache system:

  • Complexity will be added to your application.
  • Unexpected behaviors may appear if not using it correctly.
  • The Object Model Cache provided by default is an in-memory cache, so it cannot be shared between servers.
  • It is not interesting to use a Cache system if the cached data changes too often. It’s best to cache immutable or almost immutable data.

 
An example scenario when the Object Model Cache feature could be useful may be when storing “referential” data on a data base or data that does not change too often.
 
CodeFluent entities provides three types of Cache implementations:

  • Simple Cache Manager, based on the ASP .NET cache (that can be used outside of ASP.NET)  (CodeFluent.Runtime.Caching.SimpleCacheManager, CodeFluent.Runtime).
  • Simple Localized Cache Manager, a sub-class of the Simple Cache Manager that can manage localized keys (CodeFluent.Runtime.Caching.LocaleCacheManager, CodeFluent.Runtime)
  • Enterprise Library Cache Management, you must install the Enterprise Library in order to use it (CodeFluent.Runtime.Caching.EnterpriseLibraryCacheManager, CodeFluent.Runtime).

 
You can specify the type of cache you want to use on the “Runtime Cache Type Name” attribute (the full type name). You can use a different cache systems by scope (entity, method).
 

Runtime Cache Type Name

Runtime Cache Type Name


 

You can use a different or custom type of cache not provided by CodeFluent Entities, you only need to implement the CodeFluent.Runtime.Caching.ICacheManager interface.

 

Finally, you can disable the cache feature by configuration (only for the Simple Cache Manager and the Simple Localized Cache Manager), for a testing or development environment for example. You only need to add the following code to your app.config or web.config file:
 

<appSettings>
   <add key="CodeFluent.Runtime.Caching.SimpleCacheManager.Enabled" value="false"/>
</appSettings>

 
 

Regards,
 
Pablo Fernandez Duran
 
 

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

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

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?

or

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.

Cheers,

Carl Anderson

CodeFluent Entities: Attributes

February 23, 2012 1 comment

Using CodeFluent Entities you can define attributes on other concepts such as Entities, Methods or Properties and what gets really interesting is that the .NET Business Object Model Producer translates those CodeFluent Entities Attributes into actual .NET attributes Smile

Now say you want to specify some specific attributes on your generated .NET classes or data annotations on your properties, defining attributes in your model would be the way to go!

To do so select your concept such as a property and click on “Add Attribute” in the ribbon, the following dialog will show up:

image

In the attribute name set the full type name of your attribute such as System.ComponentModel.DataAnnotations.RequiredAttribute”.

Note: Setting the attribute class using the drop down list in the lower part of the form allows you to specify where this attribute should be placed in the generated classes. Default is in the entity class, but you can also place it in the service class, the service interface, or the proxy class.

In the screenshot below we defined a Required data annotation attribute on the Name property of our entity:

image

Then here’s the output after generating our model over:

[System.ComponentModel.DataAnnotations.RequiredAttribute()]
[System.ComponentModel.DefaultValueAttribute(default(string))]
[System.Xml.Serialization.XmlElementAttribute(IsNullable=true, Type=typeof(string))]
public string Name
{
    (…)

To specify a parameter to your attribute, go back to your model, select your attribute and click on the Arguments property in the property grid:

image

And let’s add an error message to our required attribute:

image

Generate over and here’s the result:

[System.ComponentModel.DataAnnotations.RequiredAttribute(ErrorMessage="Name is required")]
[System.ComponentModel.DefaultValueAttribute(default(string))]
[System.Xml.Serialization.XmlElementAttribute(IsNullable=true, Type=typeof(string))]
public string Name
{
    (…)

 

Carl Anderson

CodeFluent Entities: Automatic Traces Sub-Producer

February 7, 2012 1 comment

Since fall, CodeFluent Entities ships an Automatic Trace sub-producer which can be added on top of the Business Object Model producer, and which will add traces to declared properties and methods.

To use it, right-click on your Business Object Model producer and select “Add New SubProducer”:

image

Keep everything by default and click “OK”:

image

Generate over again, and taadaa! All your .NET classes now have traces:

image

Please note that by default generated traces use the System.Diagnostics.Trace.WriteLine method, but this can be customized. For instance you could set the producer to use the System.Diagnostics.Debug.WriteLine or even your own custom method Winking smile

Isn’t life beautiful?

Carl Anderson

Follow

Get every new post delivered to your Inbox.

Join 49 other followers