Microsoft Stack 2013

Recently there has been a lot of flux in the Microsoft stack, leaving developers and leads wondering which technologies they should focus on. Microsoft's unwillingness to officially deprecate technologies such as Silverlight, instead allowing them to slowly fade away, only compounds the confusion. One way to find out is to review a little known document called the ".NET Technology Guide for Business Applications". Released earlier this year, the Guide offers insight into where Microsoft intends to put its efforts and what technologies should be avoided.

This overview is a good place to start your exploration of Microsoft and related technologies.

(Click on the image to enlarge it)

Try to Leave Silverlight and Flash Soon

While even old .NET staples like WinForms and Web Forms have found a place, RIA containers such as Silverlight and Flash are definitely out. As you can see in figure 5-15 (below), Microsoft doesn't want to wait around for Silverlight 5's planned 10 year lifecycle. They intend to squeeze out RIA containers by the end of 2015.

(Click on the image to enlarge it)

For high-end applications, fully native technologies are preferred. On the low end, the capabilities of HTML5 are expected to continue to grow. While not pushing developers to go one way or the other, here is what they have to say about the transition:

• If you are transitioning to native applications, you can leverage your existing skills and even code by targeting XAML/.NET natively on any Windows device. Portable libraries will also allow you to share your binaries between different platforms, including Silverlight.
• For browser-based HTML5 apps, Microsoft provides leading tools and frameworks to help you create applications for any device based on the latest standards. Silverlight's interoperability with HTML also enables a gradual transition through hybrid applications.

Mobile

Three Equal but Different Options for Windows 8 Store

In the past Microsoft has been reluctant to push developers onto a specific stack when it comes to Windows 8 Store apps. This policy hasn't changed; the number one criteria for choosing between .NET/XAML, C++, and JavaScript/HTML5 is simply which one the developer is most familiar with.

Beyond that, they cite C++ for its performance advantages. Reusability isn't a high concern because all three platforms are capable of sharing code and resources across Windows Phone and Windows desktop.

Native Options for Windows Phone

On Windows Phone the recommended technologies are .NET and C++. Again there is a nod to C++'s performance advantage, but mostly they are saying developers should use whatever they are more familiar with.

Though Windows Phone is compatible with PhoneGap/Apache Cordova, it isn't mentioned at all. Presumably this is because they view PhoneGap as having poorer performance than .NET or C++ on small devices. At the 2013 Build conference performance was far and away the most important topic, pushing out other considerations such as general usability, visual design, and deep OS integration.

Mobile Web: Anything but Web Forms

If choosing a web-based solution to work across all mobile devices the choices are numerous. ASP.NET MVC with Modernizer is the base line recommendation, with the option of building a Single Page Application (ASP.NET SPA) where appropriate. Microsoft considers SPA to be more design pattern than technology, with Knockout and Breeze being highly recommended libraries.

For quickly putting together CRUD style applications LightSwitch is on the table. This offers little control over the HTML rendering, but doesn't require the overhead of having developers build their own layouts for various screen sizes.

ASP.NET Web Pages are the fourth option offered for mobile web. Based on the Razor syntax, this offers a development experience similar to scripting languages such as PHP or classic ASP.

Not mentioned is the older ASP.NET rendering toolkit, Web Forms. While still in active development and theoretically capable of rendering device-specific HTML, in practice Web Forms hasn't lived up to its potential. The HTML and JavaScript it renders tends to be inefficient and view state, which is integral for its more advanced features, can quickly overwhelm a phone's network connection.

Services

Since most applications rely on external data storage and processing, server-side development continues to be an important consideration. There are currently 6 technology options Microsoft considers to be viable.

First Choice: ASP.NET Web API

According to Microsoft, the default choice for new projects should be ASP.NET Web API. This can be used when developing services that follow REST patterns and is meant to be compatible with Internet caches such as "Akamai, Windows Azure CDN, Level3, and so on".

When using Web API developers should focus on OData, which standardizes the way REST endpoints are exposed, and JSON.

Second Choice: WCF

Not being tied to any specific transport protocol or message format, WCF is considered to be a more flexible option than Web API. You can, for example, take advantage of TCP or named pipes with binary messages for improved performance. The downside is that WCF can difficult to work with, especially when you want to expose data in JSON or other non-SOAP based formats.

WCF was designed with enterprise-facing, RPC-style communication in mind. While public-facing REST-style design patterns are possible, it isn't the preferred option for that use.

WCF with OData

If you are working on a mostly CRUD style service layer and want to use the WCF stack then WCF Data Services is the way to go. This shares the OData libraries with ASP.NET Web API and is often used in conjunction with Entity Framework.

Workflow Services

Workflow Services are a marriage of Windows Workflow and WCF. The only reason to use this is if your services are already using Windows Workflow internally. Microsoft cites no other reason for choosing this option.

SignalR for Two-Way Communication

If you are only using.NET based clients, WCF offers lots of options for fine tuning two-way communication. But if you want something that can support both .NET and web-based clients then SignalR is a tempting choice.

According to Microsoft, SignalR can scale to "even millions of users". For web clients it prefers to use WebSockets, but can automatically fall back to older patterns like long polling if necessary.

SignalR also has a library for .NET clients, allowing web and native clients to share services.

LightSwitch, Another OData Provider

It is hard to overstate how much Microsoft loves OData. We've already seen OData for both WCF and Web API, but it doesn't end there. Though normally used with LightSwitch clients, you could conceivably use LightSwitch's server side capabilities to quickly generate a service tier.

Microsoft claims LightSwitch requires no coding, but warns that it comes with a loss of flexibility.

Guidance for Small and Medium Business Applications

Microsoft wrote its guidance for small and medium size businesses with these goals in mind:

• Complete velocity and shorter time to market
• Productivity and lower costs
• Easy to get started
• Collaboration and Integration with market products
• Cloud agility and cost reductions opportunities

Translated to plain English, this means, "make it quickly and make it cheaply". Their specific guidance depends on what presentation mode you prefer.

Web Apps for Small/Medium Businesses

For quick and dirty CRUD style applications, Microsoft is continuing to push LightSwitch as the go-to platform. It was originally described as a tool for non-professional programmers to use. Many thought of it as a multi-tier replacement for Access. That vision seems to have faded as LightSwitch is now being offered more as a tool for IT departments that need to quickly push out applications.

Next up is Web Forms. Yes, the venerable Web Forms technology is still being recommended for use in new projects. Microsoft sees it as a middle ground between the easy to use but limited LightSwitch and the complexity of ASP.NET MVC. With features such as rich data grids, Web Forms are still well suited for a company's suite of internal applications.

ASP.NET Web Pages are mentioned, but only briefly. If you want more control over rendering than Web Forms offers, ASP.NET MVC is the tool of choice. However, Microsoft does warn about its longer learning curve.

Building for Windows Desktop

While all the C++ based GUI toolkits such as MFC and ATL/WTL are off the list, the original .NET UI toolkit WinForms is still considered a viable option along-side WPF. Both support modern concepts such as data binding, async/await, and two-way communication using WCF or SignalR.

The choice between WPF and WinForms involves several considerations:

First is difficulty. WinForms is much easier to understand than WPF, even for senior developers. WinForms uses very simple data binding and prefers a classic MVC or MVP approach. WPF, on the other hand, requires the user to learn a complex data binding framework in order to correctly use the MVVP pattern. Success with WPF also requires knowledge of resource dictionaries, converters, ICommands, and XAML's templating engine.

On the other hand, if you intend to also target Windows Phone or Windows 8 Store you are going to need to learn how to use XAML. In that case, starting with WPF will make it more likely you can share code across platforms.

The flexible rendering engine in WPF also allows for nicer looking applications than can generally be done with WinForms. This comes at a cost; WPF applications often run slower than comparable WinForms applications.

Mentioned in passing is the LightSwitch desktop client. Presumably, this can't offer anything that isn't available in the web client, so there doesn't seem to be much of a reason to choose this.

Client-Server Should be Avoided

When Microsoft says "client-server" they specifically mean applications that directly communicat with the database. Though they acknowledge it is still a very common pattern, they want new projects to use a 3-tier design with a service layer sitting between the client and database. This provides better scalability over direct database access and a way to bypass firewalls and other obstacles. Plus, it allows the application to be ported to platforms where database drivers simply are not available.

"Modernization" - Leaving the Windows Desktop

Microsoft offers a lot of advice on how to "modernize" desktop applications. This advice is mostly about getting the application ready to be ported to other platforms, but there is some useful guidance even if you don't plan on leaving the Windows desktop. Here is their summary:

• Use the Model-View-ViewModel design pattern (MVVM): Microsoft client platforms (including WPF) make it easy to build applications using the MVVM pattern. With this pattern you will get a strong separation of display from state and behavior, which will help you to create clean and maintainable code that can be easily shared between multiple devices.
• Use portable class libraries for the client logic: .NET portable libraries allow binaries to be shared between multiple platforms such as the desktop, Windows Store apps, Windows Phone apps, and others. Implementing your client logic with .NET portable libraries will greatly simplify the creation of multiple experiences on multiple platforms.
• Modernize your user experience: Concepts that are demanded by today's end users can be implemented with the latest innovations on .NET for the desktop. Design principles such as "fast and fluid," "authentically digital," and "do more with less" can be applied to your existing desktop application by employing a modern UI for your XAML design, carefully using animations, and implementing .NET asynchronous programming extensively.
• Move the business logic to the server: Two-tier applications (client/server) are significantly harder to extend to new devices. The recommended approach is to clearly separate the business logic into services that can be reused later on other devices and form factors.
• Extend to the cloud: Once separated from the client, Windows Azure provides multiple solutions to move the business logic to the cloud. Transforming that logic into cloud services greatly improves the elasticity and scalability of existing solutions, making them ready to embrace multi-device approaches.

.NET on Android and iOS

Microsoft is working with several partners to help with the modernization effort. Here is what they have to say about each:

• Xamarin provides a means to share C# code from your applications targeting Windows or Windows Phone with iOS and Android devices. It provides access to the underlying API to create tailored views while reusing the client logic code between devices.
• ITR-Mobility iFactr and MonoCross offers a solution for building enterprise mobile applications in C# for delivery on the major mobile platforms. It provides services such as Abstract UI and Enterprise Data Synchronization to enable business applications across a range of devices.
• Mobilize.NET by Art in Soft provides solutions and services for migrating legacy applications to modern platforms-including the web, mobile, and the cloud-by transforming the existing source code into new code without runtimes for the output application.
• Citrix Mobile SDK for Windows Applications provides a rich tool kit for developers to mobilize LOB Windows applications or write new touch-friendly applications executing on central servers (Citrix XenApp/XenDesktop) and accessed from any mobile device with Citrix Receiver.

Side note: The fact that Microsoft is actively promoting Xamarin and MonoCross should finally put to rest the long running rumors that Microsoft intends to sue the makers of Mono.

Guidance for Large, Mission Critical Business Applications

When it comes to larger companies and their mission critical applications the focus shifts from cost and productivity to complexity management and quality of service. These guidelines are not meant for data driven or CRUD applications, developers working on those should use the small/medium business guidelines. These guidelines are for systems with many interconnected parts and sub-systems with varying amounts of independence.

Web Applications in the Enterprise

Microsoft is unequivocal on this point, for mission critical web sites you should be using ASP.NET MVC. The only architectural question is whether or not to layer Single Page Application design patterns on top of it.

Other web technologies such as Web Forms or Web Pages should not be used. They simply don't offer the control and testability of the MVC stack, which in turn limits the Quality of Service that can be obtained.

Desktop Applications in the Enterprise

As with smaller applications, Microsoft is including WPF and WinForms on its recommended list. To this they add C++ with either Win32 or MFC. The use of C++ is recommended for very large, long term projects comparable in scale to Microsoft Office. One presumes they are thinking about the difference between AutoCAD and Paint.NET in terms of scale.

Windows Store/Windows Phone in the Enterprise

Microsoft doesn't really have anything to say in this section besides stating the recommendations are "similar to the recommendations available in the ‘Emerging application patterns' section". This doesn't instill much confidence but they aren't outright dismissing the platforms either.

Patterns and Practices

For roughly the last 20 pages of the Guide, Microsoft sets aside the discussion of products and turns their attention to patterns and practices.

Inversion of Control

Microsoft spends a surprising amount of time discussing dependency injection and inversion of control containers. They list nine separate Inversion of Control Containers, the majority of which are community run projects unaffiliated with Microsoft. It should be noted many of the frameworks they list are not actually IoC Containers but rather Dependency Injection frameworks.

The confusion between to two continues throughout the section with no clear indication if Microsoft prefers composite roots (a DI pattern) or service locators (an IoC Container pattern), which is rather frustrating because, as Mark Seemann argues, they are essentially opposites.

Microsoft uses the "Single Responsibility Principle" to justify the use of dependency injection. They say SRP can result in classes that could, for example, have 15 dependencies listed in its constructor. In order to "decouple" these dependencies they suggest they be removed from the constructor and instead injected using an Inversion of Control Container.

Microsoft also mentions using Aspect Orientated Programming to add another layer of indirection and to further inject dependencies.

Bounded Context and Complexity Management

In order to control complexity, Microsoft spends a few pages discussing the concept of a "bounded context". Based on the work by Eric Evans, the basic idea is to silo your applications into smaller parts with limited sharing. In the example below, there are four separate stacks with different back ends and a common UI.

(Click on the image to enlarge it)

Their recommendations in this area make a lot of sense. For bounded contexts you identify as mission critical you can use the more expensive Command and Query Responsibility Separation (CQRS) or Domain Driven Design (DDD) patterns with fully automated tests. Meanwhile ancillary bounded contexts can use a lightweight, CRUD style architecture. Legacy code will of course get its own silo where it can be isolated and slowly replaced.

Communication and Anti-Corruption

For sharing information between bounded contexts Microsoft recommends using asynchronous messaging wherever possible. This allows each silo to work independently even when other silos fail. For simple scenarios, named pipes and Microsoft Message Queues are easy options, while more complex systems need a service bus. Microsoft mentions Windows Server Service Bus, Windows Azure Service Bus, and NServiceBus without preferring one to another.

Any services exposed by a bounded context should be protected by an anti-corruption layer. Much like the parameter checks protecting public functions, a bounded context's anti-corruption layer protects the underlying data store from malformed messages. This layer verifies the incoming message, performs any necessary translations, and ensures bad data is processed and stored. This can be done using normal .NET code, but for complex scenarios with lots of frequently changed business rules, Microsoft recommends a rules engine and integration platform such as BizTalk.

Mitigating Legacy Code

The first step in dealing with legacy code is to create a facade over it. This facade should use modern techniques such as persistent, scalable caches and hide whatever patterns the old code used. Over time, the legacy code will be swapped out and the facades redirected to new service layers.

Conclusions

Microsoft is standing behind all native, web, and communication frameworks for .NET except Silverlight in the browser and .NET Remoting. They are also recommending C++ and JavaScript in several scenarios. Older platforms such as VB 6 and classic ASP are no longer being mentioned so companies still using need to migrate to newer technologies as soon as possible.

Expect to see a continued emphasis on dependency injection, especially with ASP.NET MVC and Entity Framework. BizTalk, once thought to be a dead technology, is seeing new life as companies try to integrate on-site and cloud architectures.

Refer: https://www.infoq.com/articles/Microsoft-Stack-2013

About the Author

Jonathan Allen has been writing news report for InfoQ since 2006 and is currently the lead editor for the .NET queue. If you are interested in writing news or educational articles for InfoQ please contact him at jonathan@infoq.com.

Microsoft Stack - The best of both worlds

Life was great for Microsoft developers 10 years ago. Companies were happy with going 100 percent Microsoft for their development projects. With ASP.NET on the frontend, .NET middle-tier and SQL Server on the backend, things worked very well for the most part. When they didn’t, developers just accepted that as something that came with territory. Microsoft was all but running the show. Then, at the end of the last decade, Microsoft’s 800-pound gorilla status started to unravel. Maybe it was due to the introduction of the iPhone and Microsoft missing the shift to mobile, or maybe it was because of the proliferation of open source projects, but things changed, and today those same companies need to be persuaded that going with Microsoft Stack is a good idea. This article presents eight reasons in favor of sticking with the Microsoft software stack.

Reason #1: .NET is Still One of the Best

Introduced more than 10 years ago, .NET Framework is feature-rich and thoroughly battle-tested. While it was commonplace to have to combine native development with managed code in the early days of .NET, the vast majority of development tasks are supported out of the box today. Even companies such as Oracle released components that are 100 percent .NET managed code (i.e. ODP.NET managed driver) to interface with their products. .NET API is consistent, well documented and used by millions.

The knowledge-base available via MSDN, StackOverflow and thousands of forums and blogs is massive. In my years of developing in .NET, I cannot recall an instance where I would get stuck for long on a framework bug; each time, someone had already experienced, researched and posted an answer, not always the answer I was hoping for, but still something that moved me forward. With the upcoming 2015 release, .NET Core will be open-source and available on non-Windows systems.

Reason #2: ASP.NET has Evolved

Looking back at the traditional web-to-database Microsoft stack from 10 years ago, it’s interesting to see which parts survived the test of time and which parts faded away. While the back-end of the Microsoft stack remained pretty much unchanged (we still use the same set of patterns and components, such as Dependency Injection, Tasks, Linq, EF or ADO) the front-end, the ASP.NET piece, saw a fundamental shift from “do it the Microsoft way “ (i.e. Web Forms) to “do it your way and use ASP.NET as a platform.” Today, ASP.NET is an MVC-based framework featuring robust infrastructure for authentication, bundling and routing that integrates with many non-Microsoft technologies such as Bootstrap and AngularJS. ASP.NET sites look nice on a wide range of form-factors, from phones to desktops, and its Web API capabilities make exposing web services a breeze. The framework has been open-source for a number of years, so if you get stuck on a problem, the source is available on GitHub. ASP.NET has changed, and changed for the better.

Reason #3: Simplicity of Web API and Power of WCF

My all-time favorite quote is from Alan Kay who said, “Simple things should be simple; complex things should be possible”. When Windows Communication Foundation (WCF) first came out in 2006, it was anything but simple; behaviors, endpoints, and bindings were overwhelming. So, Microsoft released Web API, an easy-to-use framework that makes exposing HTTP web services a piece of cake. With a few lines of configuration, your API turns into a secure, “industry-standard” web service.

If your use case does not fit the “standard” mold, and you need full control over how your API is exposed over the wire, you can always fall back on WCF. With the myriad of configuration options and hooks, WCF lets you custom-serialize your data, log, intercept, route message, use peer-to-peer and queuing, and much-much more. Web API, together with WCF, delivers on both tenets of Kay’s quote: if you need a simple web service, you are done in minutes with Web API; if your service requirements are complex, “all” is possible with WCF. These two technologies provide a comprehensive coverage of service scenarios and come prepackaged with the .NET framework.

Reason #4: SQL Server is as Solid as Ever

For many years, it seemed like the tidal wave of new development languages, frameworks and patterns came through the front and middle tiers and spared the database back-end. After all, the good old “SELECT” is still as much in use today as it was 20 years ago. I suppose this is due to the fact that many companies view their data as the core of their business, and keeping the integrity of that core far outweighs the excitement of trying “something new” at the database layer.

SQL Server excels at its primary role of a data keeper with a myriad of features for transactions, referential integrity, backups, mirroring and replication, but what sets SQL Server apart from competition is how well it integrates with the rest of the Microsoft stack. For rapid development, there is the Entity Framework, currently in version 6, passed adolescence and delivering well on its promise of streamlining data access. If you need computing power, the .NET Framework is loaded in-process with SQL Server, meaning you can embed .NET code as stored procedures, functions or aggregates without sacrificing performance. Pair that with the fact that SQL Server 2014 comes with in-memory tables, and you can come up with some pretty slick real-time solutions that could not be made fast enough solely with SQL and regular tables. After years in the industry, SQL Server is still on top of my list of RDBMSs.

Reason #5: It’s Easily Testable

So many times, working in corporate IT, I saw software turning into these untouchable black boxes because there were no tests, and nobody wanted to mess with the code for fear of “breaking something else”. Then, I worked on systems that had thousands of tests, and it was a great feeling to be able to tell business that, “yes, we can make these changes,” years after software had been released. The Microsoft stack is designed with testability in mind. ASP.NET MVC has hooks for dependency injection, and in version 5, dependency injection will be included in the framework itself. In the middle tier, it’s a similar story: we use dependency injection to disassociate implementation from the interface, which lets us swap production types with mocks at test time. Even on the database side, there are SQL Server Data Tools that come with templates for testing against the stored procedure layer. Testing is an inseparable part of the software development process today, and the Microsoft stack comes well equipped for this new reality.

Reason #6: Elaborate Support Ecosystem

When it comes to support, it’s nice to have a range of options, starting with community forums and ending with an actual live human being working on-site on your server. The online ecosystem for Microsoft products is one of the largest in the industry. After all, Microsoft was started by Bill Gates, a software developer himself, who saw the wide adoption by developers as the key to proliferation of Microsoft products. That meant providing these developers with lots and lots of support.

Microsoft was among the first to encourage its employees to blog about the technology they were working on, and while the rest of the industry has certainly caught up, the amount and the quality of instructional videos, guides and articles coming directly from Microsoft today is still very impressive. That layer of quality online content is supplemented by a large number of community-based support ecosystems such as StackOverflow, which are not as consistent when it comes to content quality, but are, nevertheless, far more helpful than not.

Lastly, there is always an option to pick up the phone and call Microsoft support. I rarely had to use it, but there were a handful of production emergencies when having Microsoft devs analyze core dumps saved the day. The range of support options is clearly a factor in favor for going with the Microsoft stack.

Reason #7: Microsoft Sticks to their Products

A few years back, choosing Microsoft Silverlight as the front-end for an application seemed like a valid choice, but that’s no longer the case. With the mobile trend in full swing and JavaScript frameworks dominating the front-end space, Silverlight is no longer a feasible option; nevertheless, it’s still supported by Microsoft through 2021. Microsoft sticks to its guns, which is good for those of us who have to make technology choices without having a magic eight ball to tell us what technology trend will dominate the software landscape in the future. Going with the Microsoft stack ensures that time and money is invested into technology that will be supported even if it falls out of favor with the industry.

Reason #8: Visual Studio Umbrella

A decade ago, I was spending about 50 percent of my time working in Visual Studio and about 50 percent in other tools. Today, the split is overwhelmingly in favor of Visual Studio. Microsoft’s vision for Visual Studio to be a one-stop solution for hosting IDEs is coming to fruition with many Microsoft and non-Microsoft products offering some level of integration with Visual Studio. From database development with SQL Server Data Tools to writing iPad and Android apps with Xamarin, Visual Studio provides a familiar developer experience with a consistent user interface. The same can be said about working with Microsoft Azure, a cloud platform encompassing a variety of services from database hosting to mobile services.

Visual Studio obfuscated the complexities of distributed cloud infrastructure making the experience of developing cloud applications consistent with that of developing applications not hosted in the cloud. All the pieces seem to fit together nicely under the umbrella of Visual Studio, making the overall development process very efficient.

Microsoft Stack - The Best of Both Worlds

Today, there are far more choices for writing quality software compared to 10 years ago. That is certainly a good thing because competition forces big players, such as Google, Apple, Amazon and Microsoft, to continue to innovate and not get complacent. While Microsoft has been pushed from the top of the mountain by the tech evolution of the past decade, the company has shown that it’s willing to adapt and is attuned to realities of the current technological trends. ASP.NET embraced other technologies and methodologies, many of them open source, with the original Web Forms fading into history. The .NET framework continues to evolve, breaking new frontiers with libraries for multi-threading and many-core computing. With the imminent 2015 release, the core of the framework will be open-source and portable to non-Windows platforms, which is a step in the direction of inclusiveness and transparency.

These welcomed improvements come from a company that has long-established processes for releasing software that’s tested, documented and supported. Going with the Microsoft stack brings the excitement of working with modern languages and frameworks plus the stability of being backed by a software giant with decades of experience in the development industry. This is why I am recommending the Microsoft stack today.

Read more: https://www.toptal.com/microsoft/eight-reasons-why-microsoft-stack-is-still-a-viable-choice