Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about how to use the Microsoft technology stack. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

There have been a lot of changes in the Microsoft technology stack recently, which makes developers and leaders wonder which technologies they should focus on. Microsoft itself doesn't want to officially object to technology like Silverlight, and they prefer to let it fade out of sight, otherwise the situation could be even more chaotic. If you want to know the answer to this question, you can check out the well-known document "Technical Guide for .NET Business applications". The document, released early last year, provides an in-depth discussion of what areas Microsoft intends to work on and which technologies we should avoid.

The outline below is a good starting point for us to explore Microsoft and related technologies.

Try to give up Silverlight and Flash as soon as possible

While old .NET technologies such as WinForms and Web forms still have a place, RIA containers like Silverlight and Flash are definitely out. As shown in figure 5-15 below, Microsoft does not want to wait for the 10-year life cycle planned by Silverlight 5. They are already planning to abandon RIA containers by the end of 2015.

High-end applications tend to make full use of native technologies, while low-end applications expect HTML5 capabilities to continue to grow. Although developers are not pushed to a specific technology, the things we must pay attention to for this shift are:

If you are transitioning to native applications, you can target XAML/.NET that can be run on any Windows device, so you can take advantage of your existing skills and even code. Portable class libraries also allow you to share class libraries between different platforms, including Silverlight.

For browser-based HTML5 applications, Microsoft provides the main tools and frameworks that can help you create applications that can be used on any device based on the latest standards. The interoperability of Silverlight and HTML also allows you to make a gradual transition through hybrid applications.

move

The Windows 8 store has three equal but different options

In the case of Windows 8 store apps, Microsoft has been reluctant to push developers onto a specific technology stack in the past. This policy has not changed; the primary criterion for choosing between .NET / XAML, C++, and JavaScript/HTML5 is which one developers are most familiar with.

On top of that, they also mentioned Clover because of its performance advantages. Reusability is not a big concern because all three platforms can share code and resources between Windows Phone and Windows desktops.

Local options are suitable for Windows Phone

The technologies recommended by Windows Phone are .NET and C++. Again, we need to pay attention to the performance advantages of C++, but what they say most is that developers should use technologies that they are more familiar with.

Although Windows Phone is compatible with PhoneGap/Apache Cordova, this is not mentioned. The speculative reason may be that they think PhoneGap is worse than .NET or C++ on small devices. Performance was undoubtedly the most important topic at the Build conference in 2013, going beyond other topics such as general usability, visual design, and deep OS integration.

Mobile Web: can be used, except for Web forms

If you want to choose a Web-based solution that runs on all mobile devices, there are many options. ASP.NET MVC using Modernizer is the baseline recommendation, and you can use it to create a single-page application (ASP.NET SPA). Microsoft's view of SPA is that it is more like a design pattern than a technology, and Microsoft highly recommends the use of Knockout and Breeze class libraries.

To quickly assemble CRUD-style applications, LightSwitch is listed. Although the framework has little control over HTML rendering, it eliminates the need for developers to build layouts for a variety of screen sizes, reducing the workload.

The ASP.NET Web page is the fourth option available for mobile Web. It is based on Razor syntax and provides developers with a development experience similar to scripting languages such as PHP and traditional ASP.

The guide does not mention the older ASP.NET rendering toolkit, the Web form. Although this technology is still under active development and can theoretically render device-specific HTML, Web forms do not realize their real potential in practice. The HTML and JavaScript it renders seem inefficient, and the view state necessary for its advanced features can quickly crush a phone's network connection.

Service

Because most applications rely on external data storage and processing, server-side development is still a very important consideration. Microsoft believes that there are now six viable technology options.

Preferred: ASP.NET Web API

According to the information provided by Microsoft, the default choice for new projects should be ASP.NET Web API. You can use this technique if you want to develop REST-style services, or if you need to be compatible with "Akamai, Windows Azure CDN, Level3, and so on" Internet caches.

Developers should pay attention to OData and JSON when using Web API, which standardizes the way REST endpoints are exposed.

Second choice: WCF

WCF is considered a more flexible option than Web API because it is not bound to any particular transport protocol or message format. For example, you can use TCP or named pipes and binary messages to improve performance. The downside is that WCF is difficult to use, especially if you want to expose data in JSON or other non-SOAP-based formats.

WCF is designed for enterprises, and the idea is RPC-style communication. Although it can also use the popular REST-style design pattern, this is not the preferred option in this scenario.

WCF and OData

If your main job is a CRUD-style service layer and you want to use the WCF technology stack, then WCF data services are a good choice. It shares the OData class library with ASP.NET Web API and is usually used in conjunction with Entity Framework.

Workflow service

Workflow service is a combination of Windows Workflow and WCF. There is only one reason to use it, and that is that Windows Workflow is already used internally in your service. Microsoft believes that there are no other reasons for you to choose this option.

Use SignalR for two-way communication

If you only want to use .NET-based clients, then WCF offers a lot of options for good two-way communication. But if you want to be able to support both .NET and Web-based clients, then SignalR is a good choice.

According to the information provided by Microsoft, SignalR can even expand to millions of users. Web clients prefer to use WebSockets, but can automatically fall back to the old mode, such as long polling, if necessary.

SignalR also has a class library for .NET clients that allows Web and local clients to share services.

LightSwitch, another OData provider

Microsoft's fondness for OData is so exaggerated that we can hardly describe it in words. So far, we have seen OData for WCF and Web API, but this is not over. Although we usually use the client side of LightSwitch, it is clear that we can also use its server-side capabilities to quickly generate a service layer.

Microsoft claims that LightSwitch does not need any coding, but also warns that it will lose flexibility.

Application Guide for small and medium-sized Enterprises

Microsoft has always followed the following goals when writing guidelines for small and medium-sized businesses:

Improve the speed of completion and shorten the time to market

Improve production efficiency and reduce costs

Easy to start

Collaboration and integration with market products

Flexibility of cloud computing and opportunities to reduce costs

To put it more colloquially, it means "make things faster and cheaper." This specific guide provided by Microsoft depends on what kind of presentation mode you like.

Web applications for small and medium-sized businesses

For fast and casual CRUD-style applications, LightSwitch is still the preferred platform recommended by Microsoft. LightSwitch was originally described as a tool for non-professional programmers. Many people see it as a multi-tier alternative to access. But as Microsoft now uses it more as a tool for IT departments that need to roll out applications quickly, that vision seems to have disappeared.

The next thing we're going to talk about is Web forms. Yes, the honorable Web form is still the recommended technology for new projects. Microsoft sees it as a compromise between easy-to-use but limited LightSwitch and complex ASP.NET MVC. Web form contains a wealth of data tables and other functions, it is still very good for applications within the enterprise.

The ASP.NET Web page is also mentioned, but only a brief introduction. If you think that the rendering capabilities provided by Web forms still don't meet your needs, you can choose ASP.NET MVC. But Microsoft warns against its long learning curve.

Build Windows desktop programs

Although all C++-based GUI toolsets (such as MFC and ATL/WTL) are not listed, the original .NET UI toolsets WinForms and WPF are still considered feasible options. Both support modern concepts such as data binding and async/await, while both can use WCF or SignalR for two-way communication.

The following factors need to be considered before making a choice between WPF and WinForms:

The first is difficulty. WinForms is easier to understand than WPF, even for advanced developers. WinForms uses very simple data binding and prefers traditional MVC or MVP mechanisms. For WPF, users need to learn a complex data binding framework before they can use the MVVP schema correctly. Successful use of WPF also requires knowledge of resource dictionaries, converters, ICommands, and XAML template engines.

On the other hand, if you are going to target Windows Phone or Windows 8 stores, then you need to learn how to use XAML. In this case, starting with WPF makes you more likely to share code between different platforms.

WPF's flexible rendering engine renders more beautifully than common WinForms applications. Of course, this comes at a cost. Under the same conditions, WPF applications usually run slower than WinForms applications.

By the way, the LightSwitch desktop client. It doesn't seem to provide anything that can be used in a desktop client, so there doesn't seem to be much reason to choose it.

Client-server mode should be avoided

When Microsoft talks about "client-server", they are actually referring to applications that communicate directly with the database. Although they admit that this is still a very common pattern, they want the new project to use a three-tier design to create a service layer between the client and the database. This provides better scalability than accessing the database directly, as well as a way to bypass firewalls and other obstacles. In addition, it allows applications to be migrated to platforms where database drivers are not available.

"Modernization"-abandon Windows desktops

There are a lot of suggestions on how to "modernize" the desktop application Microsoft. Most of the tips below are about getting ready to migrate applications to other platforms, but even if you're not ready to give up the Windows desktop, they are still useful to you. A summary of the relevant recommendations is as follows:

Use the Model-View-View Model (MVVM) design pattern: the Microsoft client platform (including WPF) makes it easy to build applications using the MVVM pattern. With this pattern, you can separate presentation from state and behavior, and create clean and maintainable code that can be easily shared between different devices.

Client logic uses portable class libraries: .net portable class libraries allow us to share binaries across multiple platforms, such as desktops, Windows store applications, Windows Phone applications, and other platforms. Implementing client-side logic using .NET portable class libraries can greatly simplify the creation of multiple experiences on multiple platforms.

Improve the user experience: the ideas that end users need today can be implemented using the latest innovations in .NET for the desktop platform. Design principles such as "fast and smooth", "get back to basics" and "get twice the result with half the effort" can be applied to existing desktop applications through the use of modern UI in XAML design, the careful use of animation, and the widespread implementation of .NET asynchronous programming.

Move business logic to the server: two-tier applications (client / server) are difficult to extend to new devices. The recommended approach is to separate the business logic into very clear services and then reuse those services on other devices.

Extend to the cloud: once the business logic is separated from the client, it can be moved to the cloud with the help of a variety of solutions provided by Windows Azure. Transforming this logic into cloud services can greatly increase the resilience and scalability of existing solutions and prepare them to embrace multiple devices.

.net on Android and iOS platforms

Microsoft is working with a number of partners to help users modernize. Here is what you must say for each partner:

Xamarin is a cross-platform development tool that enables applications targeting Windows, Windows Phone, iOS and Android devices to share C # code. We can use it to access the underlying API and create custom views while reusing client-side logic code between devices.

ITR-Mobility iFactr and MonoCross provide a solution that allows us to use C # to build enterprise mobile applications that can run on major mobile platforms. It provides services such as abstract UI and enterprise data synchronization that allow business programs to span multiple devices.

Mobilize.NET, from Art in Soft, provides solutions and services that help users migrate legacy applications to modern platforms, including Web, mobile, and the cloud. The method is to convert the existing source code into new code that does not have a runtime.

Citrix Mobile SDK for Windows Applications provides developers with a wealth of toolkits to help them move LOB Windows applications or write new touch-friendly applications that can be executed on a central server (Citrix XenApp/XenDesktop) and can be accessed from any mobile device using Citrix Receiver.

Side note: the fact that Microsoft is actively promoting Xamarin and MonoCross should eventually quell rumors that Microsoft intends to sue Mono manufacturers.

Guide to large, critical business applications

For large enterprises and their critical business applications, the focus is no longer on cost and productivity, but on complexity management and quality of services. The following guidelines are not suitable for data-driven or CRUD-style applications, and developers who do this should refer to the small and medium-sized business guide. These guidelines apply to systems with many interrelated parts and a large number of independent subsystems.

Enterprise Web applications

Microsoft's attitude on this point is clear, and they believe that key Web sites should use ASP.NET MVC. The only architectural question is whether the single-page application design pattern should be used on it.

Other Web technologies, such as Web forms and Web pages, are not recommended. Because they do not have the controllability and testability of MVC, this in turn limits the quality of services available.

Enterprise desktop application

For small applications, WPF and WinForms are still included in Microsoft's recommended list. They also added C++ and Win32/MFC in this scenario. Microsoft recommends using C++ for large, long-term projects that can be compared to Microsoft Office. One assumption here is that AutoCAD and Paint.NET are different in size.

Enterprise Windows Store / Windows Phone

For this scenario, the advice given by Microsoft is similar to that given in the "emerging Application patterns" section, but nothing else. This attitude does not instill much confidence in users, but it does not completely give up the platform.

Model and practice

At the end of the guide, Microsoft did not continue to discuss the product, but spent about 20 pages discussing patterns and practices.

Control reversal

It's amazing how much time Microsoft spends talking about dependency injection and inversion of control containers. They list nine separate control inversion containers, the most important of which is a project run by a community that is not affiliated to the Microsoft. It should be noted that many of the frameworks they list are not IoC containers in the real sense, but dependency injection frameworks.

Microsoft doesn't make it clear in this section whether it prefers composite roots (a DI model) or service location (an IoC container model), so users still have doubts about the two, which is rather frustrating because, as Mark Seemann said: they are essentially opposing.

Microsoft uses the "single responsibility model" to demonstrate the use of dependency injection. For example, they say that SRP may result in 15 dependencies in the constructor of a class. To "decouple" these dependencies, they suggest removing them from the constructor and then injecting them using a control inversion container.

Microsoft also mentioned that you should use aspect-oriented programming to add some other indirect layers and further inject dependencies.

Boundary context and complexity management

To control complexity, Microsoft spent several pages discussing the concept of "boundary context". According to Eric Evans, its basic idea is to divide the application into smaller parts, using limited sharing between the parts. The following example has four separate stacks that use different backends and a common UI.

(click to enlarge the picture)

Microsoft's suggestion in this section is very reasonable. For boundary contexts that are identified as critical tasks, you can use more expensive commands, query separation of responsibilities (CQRS) or domain driven design (DDD) patterns, and fully automated testing. At the same time, auxiliary boundary contexts can use lightweight, CRUD-style architectures. Of course, legacy code will have its own repository, where it will be isolated and slowly replaced.

Communication and protection

If you want to share information between boundary contexts, Microsoft recommends using asynchronous messages as much as possible. In this way, each part can work independently, even if one part fails, it will not affect the other parts. For simple scenarios, named pipes and Microsoft message queues are easier options, while more complex systems require a service bus. Microsoft mentioned Windows Server service bus, Windows Azure service bus, and NServiceBus, but did not say which one he preferred.

All services exposed by the boundary context should have a protection layer to protect them. Just as parameters should be checked to protect common functions, the protection layer of the boundary context protects the underlying data store from malformed messages. This layer validates incoming messages, performs all necessary transformations, and ensures that bad data is processed and stored. Users can implement it in plain .NET code, but for complex scenarios with many frequently changing business rules, Microsoft recommends using a rules engine and an integration platform, such as BizTalk.

Dealing with legacy code

The first step in dealing with legacy code is to create an appearance layer for it. The appearance layer should use modern techniques, such as continuous, extensible caching, and should hide all patterns used by the old code. Over time, the legacy code will be replaced and the appearance layer will be redirected to the new service layer.

Microsoft recommends using all the. NET native, Web, and communication frameworks, with the exception of Silverlight and .NET Remoting on the browser side. They also recommend C++ and JavaScript in some scenarios. Older platforms like VB 6 and traditional ASP are not mentioned at all, so companies that are still using these technologies should migrate to new technologies as soon as possible.

Unsurprisingly, Microsoft continues to emphasize dependency injection, especially their combination with ASP.NET MVC and Entity Framework. The trend of enterprises trying to integrate on-premises and cloud architectures gives hope that BizTalk, once thought to be dead, will come back to life.

The above is the editor for you to share how to use the Microsoft technology stack, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.