Three Telcos under the Malaysian sky
Seven point five the OS of Windows Phone
Nine Nokia Stores are where to buy
One phone each for us to bring home
At the launch of Lumia where the excitement rise
One phone to rule them all, one place to find them
One App to bring them all and in the Marketplace binds them
At the launch of Lumia where the excitement rise
I have always been a Nokia fan-girl and it would be interesting to see how Nokia fairs with its latest Lumia 800, their first Windows Phone 7 phone (I know it sounds a bit weird) in Malaysia. At the point of this writing, Digi has even thrown in a very good deal.
Nokia is also giving out lotsa freebies to the first 100 Lumia 800 customers at the launch on Feb 10, 2012 starting from 5:30pm at Pavillion (and other Nokia Stores).
Thursday, February 09, 2012
Monday, February 06, 2012
Layered Architecture Solution Guidance 1.0.0.5
Finally got the time to post this. Layered Architecture Solution Guidance 1.0.0.5 is now available for download. This version comes with several enhancements and productivity improvements.
Delete Buttons - They are back! One of my developers have previously mentioned that the buttons were confusing but I noticed people deleting the whole class definition instead of using the Del key to remove an individual property/method. Therefore, I made a conscious decision to bring back the delete buttons :)
Re-order Properties/Methods - You can now re-order the property/method definitions before code generation. Inertia and Momentum have an additional Sort option.
Add All Sources - There is now an option in the code generators to create definitions for all sources at once instead of requiring you to select and configure one-by-one. However, this will only use the basic configuration. This option is not available in Motion and Vector.
Momentum Enhancements - Momentum has been slightly upgraded to support the following features:
Motion Enhancements - Motion has also been upgraded to support the following:
Other Code Generator Enhancements
Delete Buttons - They are back! One of my developers have previously mentioned that the buttons were confusing but I noticed people deleting the whole class definition instead of using the Del key to remove an individual property/method. Therefore, I made a conscious decision to bring back the delete buttons :)
Re-order Properties/Methods - You can now re-order the property/method definitions before code generation. Inertia and Momentum have an additional Sort option.
Add All Sources - There is now an option in the code generators to create definitions for all sources at once instead of requiring you to select and configure one-by-one. However, this will only use the basic configuration. This option is not available in Motion and Vector.
Momentum Enhancements - Momentum has been slightly upgraded to support the following features:
- Support for Schema
- New "Insert | Update | Delete | Select" method type.
- New "Standard CRUD Methods" method type that generates an extra Select All method.
- Option to generate "Load methods" to reduce code repetition. Please use with caution to avoid duplication.
Motion Enhancements - Motion has also been upgraded to support the following:
- More streamlined DAC method selection.
- Support for drag-and-drop of DAC methods to selection.
Other Code Generator Enhancements
- Inertia - Allows you to type in the data type for your properties. You can use this as a convenient way to map to your enumerations.
- Vector - Reorganized UI Layout.
- Velocity - Option to generate Workflow service configuration in host config.
Thursday, February 02, 2012
SQL Azure Data Sync Preview
Was reading up on SQL Azure Data Sync and found out these interesting things:
At the time of this post, SQL Azure Data Sync (Preview) does not support bigint data type.
http://msdn.microsoft.com/en-us/library/hh667319.aspx
One need to be very careful when selecting the Conflict Resolution strategy. Apparently, both Hub or Client Wins will also result in some form of data loss if the resolution is not understood properly.
http://msdn.microsoft.com/en-us/library/hh667306.aspx
Finally, I think this is the most important and missing this one out would have caused a lot of issues (and $$$) later - Synchronization Loops.
http://msdn.microsoft.com/en-us/library/hh667312.aspx
At the time of this post, SQL Azure Data Sync (Preview) does not support bigint data type.
http://msdn.microsoft.com/en-us/library/hh667319.aspx
One need to be very careful when selecting the Conflict Resolution strategy. Apparently, both Hub or Client Wins will also result in some form of data loss if the resolution is not understood properly.
http://msdn.microsoft.com/en-us/library/hh667306.aspx
Finally, I think this is the most important and missing this one out would have caused a lot of issues (and $$$) later - Synchronization Loops.
http://msdn.microsoft.com/en-us/library/hh667312.aspx
Friday, January 06, 2012
MVP for Windows Azure
On January 2, 2012, I was awarded the Microsoft Most Valuable Professional (MVP) for Windows Azure. It is really an honor to be recognized as a Windows Azure MVP for my country. I will definitely continue to shower the developer community with my passion for technology and crazy ideas to build applications - particularly now focusing on Windows Azure. :)
Wednesday, January 04, 2012
Windows Azure is now ISO 27001
I am just going to parrot this from the Windows Azure Team Blog. Windows Azure is now ISO 27001 certified and more importantly it complies with the ISO/IEC 27001:2005 ISMS requirement standards. This is a good start and a great milestone to gain the confidence of ISO 27001 companies (like my current) to leverage on Windows Azure.
The next step would be to see SQL Azure getting certified. Getting SQL Azure certified will be the most important key point to address the data concerns of most companies when moving into Cloud solutions. Looking forward to see that happen.
The next step would be to see SQL Azure getting certified. Getting SQL Azure certified will be the most important key point to address the data concerns of most companies when moving into Cloud solutions. Looking forward to see that happen.
Monday, December 05, 2011
MVC and Layered Architecture
Throughout the years of promoting Layered Architecture on .NET, I have occasionally came across the question on how to integrate the Model-View-Controller (MVC) Architecture into Layering. MVC provides clear separation of data and UI logic concerns coupled with the benefits of high testability. Layered Architecture provides a scalable, extensible, maintainable and highly adaptable distributed design for applications. With such advantages from both architectures, who can resist them? :)
Back then, there weren't any sophisticated MVC tools in Visual Studio, the closest was the Smart Client Software Factory (SCSF) and Web Client Software Factory (WCSF), but both were using rather complicated implementations. But today, VS 2010 provides us with ASP.NET MVC web application templates which effectively raises the need to answer the integration question even further.
Before I discuss the integration ideas, I would like to first share with you my personal perspective of the MVC architecture. Firstly, MVC is an out-dated (but good) architecture. Many sites will tell you that MVC is not new and it has been around since SmallTalk. Why I say it is out-dated is because it was not designed for today's service-oriented distributed architectures (something that can be fixed when merged with Layering).
Secondly, I view MVC as a "micro-pattern" for developing UI applications and Layering as a "macro-pattern" that can house multiple micro-patterns (not just limited to MVC). Therefore, I truly believe that MVC can be integrated into Layering to leverage on modern day distributed environments.
Finally, I felt that the out-of-the-box ASP.NET MVC templates in VS2010 are encouraging a monolithic approach. Ok, I admit that I think most of the OOTB VS templates are *evil*, simply because their focus is on RAD and promoting the adoption of a specific technology without looking at the complete architecture. Some developers have already realized this and have started to decouple their Data Layers to a Data Service, but that still leaves them with a "client/server application" at best. Do take note that all these problems I highlighted are not the fault of the developers but more on the project templates.
I shall reserve my ideas to fix those templates to another post, but right now, I will provide the high-level concepts of merging the two architectures to get the best of both worlds. There are two models which I have came up with and I will start off with the first one which I conveniently termed it as the Bridged Model.
If we dissect both architectures, we can easily identify components of similar responsibilities regardless of the term that is used. In MVC, the Model is used to ferry data, the View is used to display/capture data and the Controller is used to process logic and co-ordinate the flow between Views. In Layered Architecture, the Business Entities are used to ferry data, UI Components are used to display/capture data and the UI Process Components are there to co-ordinate the UI (and connect to the service back-end) - Notice the similarities?
In the Bridged Model, the key to connecting both architectures lies in the Controller component of the MVC and the UI Process Component (UIPC) of the Layered Architecture. By connecting the Controller to the UIPC, we treat the entire MVC portion as a UI layer (or component) sitting on top of the UIPC. This strategy has the benefit of making the Controller more lightweight as most of the application and service-communication logic is delegated to the UIPC. It is also good for multi-UI platform applications which may allow Desktop, RIA and mobile clients to share the same UI processing logic.
If you are integrating a MVC web application to an application with existing UI components calling a service back-end, then the Bridge Model will make most sense.
While the Bridge Model works in connecting the two architectures, it may seem less elegant if we only have a single UI platform. In that case, we may not want the performance overhead of the Controller-UIPC relationship and to remedy it, we can adopt the Integrated Model.
In the Integrated Model, the Presentation Layer components are being replaced completely with the MVC components. The responsibility of the UIPC is unified into the Controller, eliminating one level in the UI and therefore, improving the performance of the application.
Whether to use the Bridge Model, Integrated Model or not at all, is depending on your choice and the projected application growth. If you are dead-sure that your application will not grow, then the monolithic approach presented by the OOTB templates will work just fine. Otherwise, if you share the same thoughts like me i.e. "All applications has the potential to grow, no matter how small they are", then it may be wise to look at the integration models from the start.
Take note that although I used Web Application in the context of the discussion, these concepts can be equally applied to any type of MVC application i.e. the SCSF implementation of MVC/MVP.
Back then, there weren't any sophisticated MVC tools in Visual Studio, the closest was the Smart Client Software Factory (SCSF) and Web Client Software Factory (WCSF), but both were using rather complicated implementations. But today, VS 2010 provides us with ASP.NET MVC web application templates which effectively raises the need to answer the integration question even further.
Before I discuss the integration ideas, I would like to first share with you my personal perspective of the MVC architecture. Firstly, MVC is an out-dated (but good) architecture. Many sites will tell you that MVC is not new and it has been around since SmallTalk. Why I say it is out-dated is because it was not designed for today's service-oriented distributed architectures (something that can be fixed when merged with Layering).
Secondly, I view MVC as a "micro-pattern" for developing UI applications and Layering as a "macro-pattern" that can house multiple micro-patterns (not just limited to MVC). Therefore, I truly believe that MVC can be integrated into Layering to leverage on modern day distributed environments.
Finally, I felt that the out-of-the-box ASP.NET MVC templates in VS2010 are encouraging a monolithic approach. Ok, I admit that I think most of the OOTB VS templates are *evil*, simply because their focus is on RAD and promoting the adoption of a specific technology without looking at the complete architecture. Some developers have already realized this and have started to decouple their Data Layers to a Data Service, but that still leaves them with a "client/server application" at best. Do take note that all these problems I highlighted are not the fault of the developers but more on the project templates.
I shall reserve my ideas to fix those templates to another post, but right now, I will provide the high-level concepts of merging the two architectures to get the best of both worlds. There are two models which I have came up with and I will start off with the first one which I conveniently termed it as the Bridged Model.
If we dissect both architectures, we can easily identify components of similar responsibilities regardless of the term that is used. In MVC, the Model is used to ferry data, the View is used to display/capture data and the Controller is used to process logic and co-ordinate the flow between Views. In Layered Architecture, the Business Entities are used to ferry data, UI Components are used to display/capture data and the UI Process Components are there to co-ordinate the UI (and connect to the service back-end) - Notice the similarities?
In the Bridged Model, the key to connecting both architectures lies in the Controller component of the MVC and the UI Process Component (UIPC) of the Layered Architecture. By connecting the Controller to the UIPC, we treat the entire MVC portion as a UI layer (or component) sitting on top of the UIPC. This strategy has the benefit of making the Controller more lightweight as most of the application and service-communication logic is delegated to the UIPC. It is also good for multi-UI platform applications which may allow Desktop, RIA and mobile clients to share the same UI processing logic.
If you are integrating a MVC web application to an application with existing UI components calling a service back-end, then the Bridge Model will make most sense.
While the Bridge Model works in connecting the two architectures, it may seem less elegant if we only have a single UI platform. In that case, we may not want the performance overhead of the Controller-UIPC relationship and to remedy it, we can adopt the Integrated Model.
In the Integrated Model, the Presentation Layer components are being replaced completely with the MVC components. The responsibility of the UIPC is unified into the Controller, eliminating one level in the UI and therefore, improving the performance of the application.
Whether to use the Bridge Model, Integrated Model or not at all, is depending on your choice and the projected application growth. If you are dead-sure that your application will not grow, then the monolithic approach presented by the OOTB templates will work just fine. Otherwise, if you share the same thoughts like me i.e. "All applications has the potential to grow, no matter how small they are", then it may be wise to look at the integration models from the start.
Take note that although I used Web Application in the context of the discussion, these concepts can be equally applied to any type of MVC application i.e. the SCSF implementation of MVC/MVP.
Friday, November 25, 2011
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? ^_^
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? ^_^
Wednesday, November 23, 2011
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.
"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.
Monday, November 21, 2011
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! ^_^
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! ^_^
Tuesday, November 15, 2011
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.
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. ;)
Subscribe to:
Posts (Atom)