LASG = A framework?

I was approached by a developer to comment about the usage of some frameworks in his project. After providing my comments, I told him that I do not use the frameworks that he had mentioned and he immediately said, "Oh! I forgot, you only use LASG". I was stunt for a moment. Probing further, I managed to discover how LASG was being perceived (somewhat wrongly) by some developers in the community.

Firstly, I discovered that the developer had compared LASG with MVC (some had previously compared it with ADO.NET Entity Framework). MVC and EF are both "code-frameworks" that share the same goal as LASG which is to simplify software development but uses a completely different category of approach. I would say, MVC and EF are what (true and real) code-frameworks should be.

LASG is not a code-framework but only a simple (humble) automation tool. It does not contain any APIs or Application Blocks that requires a developer to learn or use. It is just a combination of project templates and code-generators that simplifies development tasks. These tasks can very well be hand-coded if one wishes to do it. Therefore, I feel that getting started with LASG is (should be) much simpler and easier as compared to learning a code-framework.

To prove a point, you can completely disassociated LASG from your Solution and Project templates at any time and your code will still compile and run. You can uninstall LASG from your machine after you have generated all the code and your code will still compile and run. [Warning: If you disassociate LASG from your projects, you will not be able to re-associate it back. Hey! It has feelings too you know! :p].

I also understand that this confusion is also partially my fault. For the veterans who knew me previously, I wrote a RAD framework called Paladin and to accelerate the adoption, I developed a simple code-generator on top of the framework. That was the time when people proclaimed that Paladin was a code-generator but I refuted and said it was a framework. Now almost 10 years after that, I created something simpler like LASG and people now have the perception that it was something complex like my previous attempt. *HeHe*

So, is LASG still a framework? If I follow Microsoft Patterns & Practices' (or the industry) terminology, LASG is somewhat like a software-factory - a very basic one I would say (All great things start with a baby step). Afterall, it does provide guidance and recipes to build software and you can adapt it to any compatible code-frameworks (if you are creative enough). If we must have the word "framework" attached to it, I will call it an "Architecture Framework".

Still confused? Why don't you download it first and then tell me? ^_^

Sharing Code Between .NET and Silverlight

Recently, I have some time to look into the solution for sharing code between .NET and Silverlight again. It was an annoyance which everyone of us (including developers around the world) discovered, where we can't reuse our .NET classes in Silverlight. Any attempt to add reference to our .NET assemblies will land us the following error message:

"You can only add project references to other Silverlight projects in the solution."

If you are developing layered or multi-UI applications that involves Silverlight, then you would have encountered this error. This is not really a bug but actually is by design since both Silverlight and .NET don't share the same runtime. This is indeed bad news for those of us who try to follow proper architecture design practices since we are unable to share our entity classes.

If you packed everything to one WCF service, then you shouldn't have any problems because the "Add Service Reference" option in Visual Studio would have generated replicas of the entities into the Silverlight project. However, if you have separate services i.e. a WCF service to handle standard calls and a Workflow Service that runs workflows and both requires the same set of entities, then you will immediately run into issues because the replicas generated on both service references will not be compatible.

There is currently no out-of-the-box intelligent solution for this issue. This is a tooling limitation - I blame it on svcutil.exe. Most developers after several futile attempts will just try to manually replicate the entity classes to their Silverlight projects. This will solve the add reference issue but will introduce code inconsistencies should the entity classes are updated in future.

Fortunately, Visual Studio provides us with the "Add As Link" feature to allow us to share the same code files across multiple projects. However, this is somewhat a pain as well since we need to keep the projects synchronized when we add/remove items.

By luck, I came across this handy Visual Studio Extension - Project Linker which was part of the PRISM project. This neat tool allows us to "link" Visual Studio projects together keeping them fully synchronized so that we can have projects that share the same code base but target different platforms. It was originally designed for sharing code between WPF and Silverlight. You can also check-out the documentation here - very useful when you need to "unlink" projects ;)

So there we have it. Not a very elegant solution but at least it helps reduce the redundancy and ensure synchronization of our code.

Layered Architecture Solution Guidance 1.0.0.4

Just released the Layered Architecture Solution Guidance 1.0.0.4. If you have installed it, Visual Studio 2010 should prompt you for an update. There isn't much changes in this release other than numerous bug fixes. The most important fixes are with the Layered Azure Application and Layered Silverlight 4 Application.

The Layered Azure Application template has been updated to use the Windows Azure SDK 1.6. The Layered Silverlight 4 Application will now correctly generate the namespaces for the MainPage.xaml and App.xaml files. Previously, the project templates will create projects that would fail on execution.

The ConsoleHost project has also been dropped from automation in this release. This is to promote the use of WebHost as the recommended practice.

There is now an option to let the Momentum: DAC Gen to add the connection string to the WebHost web.config file automatically.

I had to push this version out to prepare for the enhancements planned for the next version.

Have fun and happy layering! ^_^

Tech Insights 2011

This is the first time that I have been engaged to speak in Tech Insights. This year, the event will be held at Monash University, Sunway Campus on the November 16th and 17th. Yups, that's tomorrow and the day after. I will be presenting two sessions on Windows Azure - one for each day. Both are architecture sessions (since I was specifically told to do architecture only *HeHe*)

For day 1, I will be presenting "Exploring Cloud Architectures" [Dev Track 2 - 1:30pm-2:30 pm] where I will be giving a very quick overview of Windows Azure and then dive straight into talking about how to migrate existing architectures (i.e. Monolithic, Client-Server, N-tier/3-tier, Message Bus and SOA) to Windows Azure. I will also discuss how scale-out is achieved on Windows Azure and illustrate some possible real-world hybrid architectures that leverages on Windows Azure, SQL Azure and Azure AppFabric. Finally, there will be a quick discussion on the cost and economics of leveraging Cloud solutions and also highlights on some possible architecture traps. This session will be informative for Brownfield scenarios.

On day 2, I will be presenting "Building Layered Azure Applications" [Dev Track 1 - 11:30am-12:30pm] which will feature Layered Architecture Solution Guidance (LASG) in the demos. I will be going through some key academic points on application architecture and then provide a brief explanation on the Layered Architecture design pattern (which was intentionally left out in day 1's presentation). The demo for this session will showcase how to use LASG to quickly build a simple layered application from scratch which can be deployed to both on-premise and the cloud. This session will be informative for Greenfield scenarios.

So, if you are free and are dropping by Tech Insights 2011, do attend my sessions ya. ;)

Silverlight with Controller & WCF

I have received many questions on how to wire-up a Silverlight UI to the WCF back-end in a Layered Application. I noticed most Silverlight applications being taught or structured today, are not properly layered. Most are following the Fat-Client 2-tier architecture style with business logic embedded in the Silverlight UI and data being hosted on a server (accessed via WCF Data Services).

While this sort of architecture serves its purpose as an application, it does not promote centralize/shareable business logic in the back-end. UI technologies are very volatile. Therefore, when UI technology changes, we do not want it to impact our business logic.

The first challenge in building a layered Silverlight application is of course the mindset. Once that is taken care off, the next will be to understand the challenge in the separation of concerns. In a layered application, the UI is divided into 2 component types - the UI itself and a Controller component. Many Silverlight developers face a challenge here due to the async nature of Silverlight calls to WCF.

This is caused by the Controller component which is responsible to communicate with the back-end. The existence of the Controller component causes a "disconnection" between the service calls and the UI controls.

In this post, I will attempt to provide a simple solution to address that challenge. Here's the scenario - Assuming, I have a method called ListEmployeeExpenses that takes an EmployeeID and lists out all the expenses that belong to an Employee. This method is hosted in a WCF back-end. On my Silverlight page, I have a simple Button to invoke the method and a DataGrid to display the results.

This is how I would do it:

1. In the UI.Process project, create an EventArgs class to hold the results from the WCF call. Example, I create a DataPopulatedEventArgs class.

public class DataPopulatedEventArgs : EventArgs
{
    public T Result { get; set; }
}

2. Next, create an Event and a method to raise the event in the Controller class.

public class ExpenseController
{
    public event EventHandler<EventArgs> DataPopulated;
    
    protected void OnDataPopulated(EventArgs args)
    {
        if (DataPopulated != null)
            DataPopulated(this, args);
    }
}

3. Now, let's put everything together in the method that calls to the WCF service. On the async completed event of the WCF service call, we create the EventArgs to hold the result and raise it with the DataPopulated event.

public void ListEmployeeExpenses(long employeeID)
{
    // Create proxy to WCF service.
    ExpenseServiceClient proxy = new ExpenseServiceClient();

    proxy.ListEmployeeExpensesCompleted += 
        delegate(object sender, ListEmployeeExpensesCompletedEventArgs e)
    {
        // Store the results from the call.
        var args = new DataPopulatedEventArgs<ObservableCollection<Expense>>();
        args.Result = e.Result;

        // Raise the event.
        OnDataPopulated(args);

        // Close the proxy.
        proxy.CloseAsync();

    };

    // Call the WCF method.
    proxy.ListEmployeeExpensesAsync(employeeID);
}

4. Finally, in our UI, we simply register to the DataPopulated event and bind the results to the UI Controls.

private void button1_Click(object sender, RoutedEventArgs e)
{
    // Create an instance of the controller.
    ExpenseController upc = new ExpenseController();

    // Register to the data populated event.
    upc.DataPopulated += delegate(object s, EventArgs args)
    {
        // Get the event argument.
        var dataArgs = 
            args as DataPopulatedEventArgs<ObservableCollection<Expense>>;

        // Bind to UI control.
        dataGrid1.ItemsSource = dataArgs.Result;
    };

    // Call the controller method.
    upc.ListEmployeeExpenses(6);
}

That's all to it! :) This is just one simple way to wire-up everything together. There are few other ways which I have experimented but this one seems to be the cleanest and have less code so far (not to mention easier to explain and maintain) ;)

Happy Layering your Silverlight apps!