Story of a weekly meeting

Guys, this is our weekly meeting outside of permises and it was held somewhere on the River Nile (very romantic place) and my colleagues were really enjoying the fund and the Ice-Cream, while I was photographing

Weekly Meeting – 19 June 2009

The Location:

The Marines House on River Nile (Click to go to the Map)

Rapid Entity Framework – Choose simplicity over complexity

This is an open source project that I found on CodePlex and it looks promising in terms of functionality, Hope you enjoy it.

Rapid Entity Framework: A new persistent framework

The Object Oriented Paradigm is shifting massively because coupling relational semantics into our fine grained object oriented programming designs is becoming unpopular in today’s enterprise needs and domain engineering. Because of this reasons and many more, object oriented platforms is already taking a big quantum leap since the impedance mismatches between OOP and Relational has made programming against relational database an Herculean task for most development efforts.
The industry is filled with many framework’s that contribute to this change, and “Rapid Entity Framework” is one out of many that will solve most of the mismatches that we face in the persistence industry today. Rapid Entity Framework is an open source framework that was discovered by a motivation to really solve the divide problem between relational DB and object oriented concepts.

With rapid entity framework, you can think about your business domain rather than columns and rows. Its a wise design efforts to really segregate applications according to their duties, “what they do”, this segregation methodologies applied by industry today, should be applied to database and object (Because they are different concept). A database is data centric, and should only contain data and any data manipulation semantics. While on the other hand, an object oriented architecture see object as real life artifacts.
Introducing Rapid Entity Framework
Rapid Entity Framework is another Object Oriented Relational Mapping framework with full object orientation semantics. It runs on the Microsoft .NET environment and its compliant with the .NET languages (C#, VB.NET). Rapid Entity gives you the benefits of persisting and fetching object states in a relational database system without forcing you to implement or inherit framework classes. I see Rapid Entity as the .NET version of the JAVA PERSISTENT FRAMEWORK So if you are a java developer in .NET Land here is the equivalent of JPA. To start with, let us follow a simple rapid example : with the following assumptions :

• We have a customer class that is mapped with rapid attributes against our database (Microsoft Access or MS Sql Server).
• We are using .NET version 2.0 or 3.5

Customer Class Diagram

The diagram above depicts the structure of the Customer and Address entity classes. There is a one – to – one relationship with both classes, so this will form the basis of our examples. First of all, we need to understand how to persist these entities, so i will be describing the rapid framework classes that we need to do the persistence. The snippet below shows how we can rapidly persist and manipulate an entity (Customer) in our example.

        EntityManager manager = new EntityManager();
        manager.OpenDatabaseSession();

First of all, the code snippet above is to initialize the EnitityManager class, which in this case is our entry – point to the persistent framework. We are initializing the EntityManager class with the instance of the WebConfigurationFactory. The WebConfigurationFactory class is created once in an application lifetime and it serves as the manager for database connections, and connection string. If you want to know how to setup your WebConfigurationFactory class, click Setting up WebConfigurationFactory . Most web applications that targets Rapid Entity Framework will configure the WebConfigurationFactory in their Global.asax (On_Application StartUp) file or class that is registered as HttpModule, while standalon\or console based application will use the ConfigurationFactory, both classes implements IConfigurationFactory interface.

Now let us create a Customer object and fill the fields with values :

        Customer customer = new Customer();
        customer.Country = "United Kingdom";
        customer.FName = "Ahmed";
        customer.LName = "Salako";
        customer.Message = "Hello world";

Above code is the initialization of our customer object. To do next is the initialization of an address class. The Address and Customer class are related by a one -to- one. We will initialize an address object and assign values to it and we will assign the address object to the customer object. such as follows :

        Address address = new Address();
        address.Country = "Nigeria";
        address.Customer = customer;       //You can notice the bi-directional relationship here.
        address.HouseNo = "83";
        address.PostCode = "NE 889";
        address.Street = "Gotham City";

        customer.Address = address;      //You can notice the bi-directional relationship here.

*Key Note : Make all your entity properties virtual, because the API uses ghost objects (Like Dynamic Proxy).

The code snippet above assigns an address object to a customer object. All the two objects are not yet persisted, so we will do the persistence by calling the code below :

        entitymanager.CreateNewEntity(customer);

        entitymanager.ComitAndClose();

Note that we are calling entityManager.CreateNewEntity(customer); we are creating the customer object which will in turn create the address object because their relationships in the mapping is also Cascade. which means when we make changes to customer, the changes in the address object will also be persisted. If we delete customer, the address object will also be deleted if we set the appropriate cascade.

Model-View-ViewModel Pattern

Introduction

Separating user interface code from everything else is a key principle in well-engineered software. But it’s not always easy to follow and it leads to more abstraction in an application that is hard to understand. Quite a lot design patterns try to target this scenario: MVC, MVP, Supervising Controller, Passive View, PresentationModel, Model-View-ViewModel, etc. The reason for this variety of patterns is that this problem domain is too big to be solved by one generic solution. However, each UI Framework has its own unique characteristics and so they work better with some patterns than with others.
The WPF Application Framework (WAF) provides support for the Model-View-ViewModel Pattern because this one works best with Windows Presentation Foundation (WPF) applications. This pattern is also known as PresentationModel pattern.
MSDN: A variant of the Presentation Model pattern named Model-View-ViewModel is commonly used in Windows Presentation Foundation applications.

Definition

Represent the state and behavior of the presentation independently of the GUI controls used in the interface.
The most approved description of this design pattern is done by Martin Fowler. You can read his article online on his website. The following chapters describe our specific .NET implementation of this design pattern.

Structure

The following UML class diagram shows the collaborating classes of this design pattern in a logical layered architecture.

Figure 1: The structure of the Model-View-ViewModel Pattern

Participants

The types participating in this pattern are:

• View contains the specific GUI controls and defines the appearance of the user interface.
• IView declares the interface of the View. The ViewModel can communicate over this interface with the View. Related pattern: Separated Interface (PoEA).
• ViewModel represents the state and behavior of the presentation.
• Model can be a business object from the domain layer or a service which provides the necessary data.
• Controller is responsible for the workflow of the application. Furthermore, it mediates between the ViewModels. So it promotes loose coupling by keeping the ViewModels from referring to each other explicitly. Related patterns: Application Controller (PoEA), Mediator (GoF)

Collaborations

• The View can call operations on the ViewModel directly. The ViewModel needs to communicate through the IView interface when it has to update the view.
• The View can collaborate with the Model but it should restrict this on simple data binding. It’s recommended to handle more complex operations by the ViewModel.
• The upward communication from the Model to the View or to the ViewModel is done through events. Especially, the property changed events can be raised on the Model to trigger the WPF data binding implementation. Related pattern: Observer (GoF).
• The Controller can call operations on the ViewModel directly, whereas the backward communication from the ViewModel to the Controller might be done through events. Related pattern: Observer (GoF).

Liabilities

This specific implementation of the ViewModel pattern has the following liabilities:

• The ViewModel is dependent on a specific GUI framework. We use the commanding and the weak event concept of WPF.
• When the ViewModel wants to listen to events of the model then you have to implement weak event listeners. Otherwise, you might produce a memory leak in your application. Note: The WPF data binding implementation uses the same concept internally.

Usage

The WPF Application Framework (WAF) provides some types which helps you to implement this pattern.

ViewModel class

Derive your ViewModel implementation from this class. The ViewModel class provides a default implementation of a weak event listener and it is responsible that the DataContext of the WPF view gets the instance of your ViewModel.
If your ViewModel implementation gets too big or you have low cohesion in your class then you can divide the ViewModel into a root ViewModel class and one or more child ViewModel classes. In this case your child ViewModels must pass the value ‘true’ for the child constructor parameter of the base class. Additionally, the root ViewModel has to expose its child ViewModel objects to the View (e.g. through a property) because the View has only an association to the root ViewModel.

IView interface

All WPF views that are managed by a ViewModel have to implement this interface. You can create your own interface for exposing properties and methods of the View. We recommend to inherit own View interfaces from the IView interface.

DelegateCommand class

This class provides a simple implementation for the ICommand interface. The constructor requires a delegate which is called when the command is executed. A second delegate can be passed to the constructor which is called when the command needs to refresh its state. With the second delegate it’s possible to define when the command should be disabled. The command state refresh is triggered through the RaiseCanExecuteChanged method.
This command implementation is an ideal candidate for the ViewModel. By using the DelegateCommand, the ViewModel gets informed when it should handle a user interface action (e.g. Button was clicked). You need to expose the commands in the ViewModel through properties and bind in the View on them.

Reference

• WPF Application Framework (WAF) http://waf.codeplex.com/Wiki/View.aspx?title=Model-View-ViewModel%20Pattern

Share this post :