The Layered Architecture Pattern promotes isolation as one of its benefits and with layer isolation, we are given the idea of being able to upgrade and migrate each layer to newer technologies without impacting the business logic. Having gone through few iterations of experimenting the pattern with various .NET Technologies, it has proven the idea to be somewhat accurate, and indeed the pattern proves to be a versatile architectural style that can evolve across time and sustain technology evolutions.
I used 'somewhat accurate' in my description due to certain caveats which I will disclose at the end of this post.
Through the exercise of testing the pattern, it is observed that the layers can easily be 'swapped-in' and 'swapped-out' when their interfaces are being abstracted carefully. You can download the samples from Layered Architecture Sample for .NET to see the implementations.
The January 2014 release of the samples demonstrates a variety of technologies assembled to form different flavours of layered applications. While the technology in other layers can be different, the business logic does remain intact.
To provide an easier visualization of what technology can be applied in the layers, I have came out with the following technology map. Take note that this is intended only as a basic guide and you are free to use whatever technologies you deemed fit in your environment.
For the presentation layer, we have a choice of:
- ASP.NET Web Forms
- ASP.NET MVC
- ASP.NET Web Pages
- Windows Forms
- Windows Presentation Foundation (WPF)
- Windows Store Apps
- Windows Phone Apps
It is quite common to leverage on ASP.NET for web applications. ASP.NET has many variants today to suit the skill-sets of different developers. Windows Forms are still widely used in enterprises where fast and responsive client-server desktop applications are required. For exciting UI applications, WPF is there to fill the gap and layering can be interestingly integrated to it even with the MVVM pattern.
Windows Store Apps are new in Windows 8, but both Store Apps and Windows Phone Apps are more suited to be connected to a cloud-based back-end (that can also be layered). Silverlight is being included as a rich-client technology but do take note that it is no longer being developed.
For the services layer, we have:
- Windows Communication Foundation (WCF)
- Windows Workflow Foundation (WF) hosted as a service (Workflow Services)
- ASP.NET WEB API exposing JSON or XML (POX)
- Microsoft Message Queue (MSMQ)
The most common distributed communications technology today are WEB API and WCF. For most resource-based and web-based services, WEB API is the preferred choice. It is also very suitable for providing back-ends for mobile applications. WCF still exist in large enterprises to facilitate interoperability between legacy and service-oriented systems and MSMQ is there to provide queue-based solutions.
Deploying old-style ASMX Web Services for new applications is not recommended, even-though you may encounter them in legacy systems. Traditionally, the services layer were fulfilled by RPC technologies such as Distributed Component Object Model (DCOM) and .NET Remoting. DCOM is still supported in the latest versions of Windows but .NET Remoting has been superseded by WCF. These legacy technologies should not be used in newer applications.
For the business layer, it is all based on our code and processing logic. At the most basic level, it will just be the .NET programming languages that we use to build our components, C# or VB.NET - F# anyone?
For the data layer, we have:
- ADO.NET
- ADO.NET Entity Framework
- Enterprise Library Data Access Application Block (DAAB)
Nothing beats native ADO.NET when it comes to data access performance but some may prefer a lightweight wrapper over it such as the DAAB. If you are still using LINQ2SQL, I will suggest migrating to ADO.NET Entity Framework. Other 3rd-party Object-Relational Mappers (O/RM) can also be used here as well.
Hopefully with the above technology map, you are able to get an idea of the technologies that can be used for building layered applications. Take note that in some scenarios, there can be more than one technology in a layer (i.e. WCF and Message Queue) and in some, the technologies may not be easily compatible.
The caveat which I mentioned earlier is that while minor technology upgrades can be isolated to a single layer (i.e. replacing data layer with a newer technology), major technology upgrades (i.e. migrating from WCF to WEB API) may affect more than one layers. But nevertheless, the business logic is still preserved. As a conclusion, it is always best to plan any technology upgrades for the layers carefully to minimize the impact.
This is the 4th part in the series of my Layered Architecture posts, you may also be interested in other posts in the series:
No comments:
Post a Comment