ASP. NET developers do not have to worry about the five main reasons for Node. node Five Reasons

ASP. NET developers do not have to worry about the five main reasons for Node. node Five Reasons

Oh, don't get me wrong ...... I really like Node, and I think its concept and pattern will have a profound impact on Server Web programming for a long time. Even if the Node gets angry over time, we can certainly feel the influence of it from the next awesome thing (good and/or bad) more or less ). During this period, many of us will choose it, and we will be happy together for production.

However, although the Node may be "fried chicken in red", it does not mean it won't work on the Web server. There are a large number of effective product deliveries every day, using old boring frameworks such as ASP. NET, Java EE, Rails, PHP (!) There are countless types. Well, it's even a bit crazy. You used COBOL to set up the HTTP service! Cobol mvc... Diao has been bombed. I give 320 likes (but never let me do it ).

For me who have been in this industry for nearly two decades, the advantage is that... Node proposes a new and interesting way to solve the boring problems. This is not to belittle Node. It's just that it's not the only one. Yesterday is not today, not tomorrow.

To sum up ...... If you are an ASP. NET programmer and quit your job to find Node, come on! Send me an email or tweet to let me know what you can do (or simply send a resume ...... We are hiring !). However, if you are still confused, you will find yourself entangled in the anti-comments of Node-fanboy-love ...... Continue reading.

   1. The best Node function (asynchronous I/O) already exists in. NET.

One of the greatest arguments for Node: Node uses an asynchronous non-blocking model to handle potential long-running I/O operations. This means that most of the work running on your web Application Server (database queries, external requests for web Services and other network resources, access files, etc) it will not happen in your main request processing process. You can continue to process other HTTP requests to this site with confidence. For this purpose, Node will maintain a thread pool, and those jobs will be specially scheduled to an available thread. You can define a callback function. When one of the operations that require a long operation is completed and return, Node will call this function for you. Here is an example of using mongoose. js API to query MongoDB. Pay attention to the callback function parameters and the lack of return value allocation when calling 'finone.

var query = Kitten.where ({color: 'white'});
// The only parameter of findOne () is a function that is called when findOne () is completed
// The callback function includes error handling and query result processing (can be null)
query.findOne (function (err, kitten) {
   if (err) return handleError (err);
   if (kitten) {
     console.log (kitten);
   }
});

This type of "continuous transfer" programming style is sometimes hard to grasp for inexperienced people, especially when your code is nested in many layers. However, the familiar sequence style (synchronization) has a great advantage: it provides a natural point for your execution framework to do other things, rather than (in this example) wait for query. findOne () returns. For Node, there is always something else to process the requests sent. Indeed, the initial design goal of Node is to wait for the completion of I/O because of the production bottleneck of typical web servers. Based on this observation, the Node design provides many performance advantages and scalability.

Here is the description of the advanced design of Node:

So if you are using Node, this is great. However, it is interesting that you can use the same mode in ASP. NET today! Many may be familiar with the async and await keywords originally introduced by C #5.0. In. NET web applications, they can work with other auxiliary frameworks, such as ASP. NET and Entity Framework, to achieve a non-blocking execution style like Node.

Here is a simple implementation of the ASP. net mvc controller to query the Entity Framework (this mode is also feasible with Web API ):

private DataContext db = new DataContext();
// GET: /Employee/
public async Task<ActionResult> Index()
{
    return View(await db.Employees.ToListAsync());
}
// GET: /Employee/Details/5
public async Task<ActionResult> Details(int? id)
{
    if (id == null)
    {
        return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
    }
    Employee employee = await db.Employees.FindAsync(id);
    if (employee == null)
    {
        return HttpNotFound();
    }
    return View(employee);
}

Is there any way to use async/await to Return Task <ActionResult> instead of ActionResult? This mode ensures the same continuous execution style as Node in terms of semantics. The await keyword indicates the position where the execution is paused (and the current thread can process other requests first). At this time, the EF query is executed outside the ASP. NET process. When an EF query returns, another thread is used to immediately restore the execution of the code located after 'await. In ASP. NET, the pause/restore gives us the semantics like the callback function in Node. Although there are differences in implementation, the basic principles are the same. Valuable server resources cannot be wasted waiting for the completion of expensive I/O operations.

One warning: Node supporters will tell you that the advantage of Node is that its design leads you directly into the "Success trap ". Asynchronous mode is the default mode of Node, which is very easy for Node, and you can also.. NET and other frameworks use Asynchronization. NET developers do not think so, but this is undoubtedly true. Although Node applications and ASP. NET Applications may be more asynchronous than each other, they cannot be understood as having better throughput or better scalability. Application scalability does not depend on the framework you use, but on whether your application has good scalability. If you are currently working on APS. NET, you will spend some time learning and applying asynchronous models before you think that ASP. NET lacks scalability.

   2. The simplified Node application model is also available in. NET.

Another benefit of Node is its simplified programming model and self-developed pace. You can understand and select and introduce more powerful and complex functions. To build a "real" application, Node needs to master fewer concepts than ASP. NET. This is not necessarily true, but it does give people the feeling. This is subjective, but many Node beginners think it is true.

In comparison, ASP. net mvc requires a series of chained concepts: HttpApplication, global. asax, web. config, model, view, controller, routing, behavior, and bundle. As an experienced ASP. NET developer, we take it for granted. However, imagine a 19-year-old person preparing to start web development and choosing a strange global. asax and web. it is not surprising that Node will be favored when config simply finds several lines of Javascript. Every generation will unconsciously carry out mining with Pride: "Yesterday we used a mara plow, a dry cross, and some enterprising ideas to build an HTTP service. We like it !" In addition, every generation has young people from another generation following them, turning their eyes and moving forward to use new tools and technologies.

Amount... but once again we see some new tricks and improvements learned by ASP. NET. In recent years, Microsoft has been committed to limiting the OWIN (. NET Open Web Interface) specification defined by the. NET developer community. The basic idea of this architecture is to use server-side infrastructure.. NET web application decoupling,.. NET web tracking (host, server, middleware, and application) defines a formal abstraction layer and interfaces for interaction between adjacent layers, this enhances the portability between multiple web hosts. It also serves as the basis of the Katana project. The Katana project is the implementation of OWIN by Microsoft and aims to use the traditional ASP. NET pipeline, HttpListener, IIS, host, and more to process HTTP requests.

OWIN and Katana draw on Node and many other lightweight frameworks, so the programming model is simple and friendly. Do you remember how simple "hello world" is in Node? Take a look at Katana:

public class Startup
{
   public void Configuration(IAppBuilder app)
   {
      app.Run(context =>
      {
         context.Response.ContentType = "text/plain";
         return context.Response.WriteAsync("Hello World!");
      });
   }
}

Easy! Defines behavior for any given endpoint (the simple behavior used by the above Code is shared by all endpoints of the application ). Note that the code is asynchronous by default, just like Node. Who said the old dog cannot learn new tricks!

Specifically, the above Code can run on any Katana host: iis,owin.exe(a slightly soft controller hostname, instead of node.exe), or your custom host implementation. It is very useful for Katana to run the same code on multiple hosts and servers, but Node does not.

And so on! Katana has a common IIS + ASP. NET server infrastructure, which depends on System. web, which not only includes ASP.. NET pipeline type (HttpApplication, HttpContext, IHttpModule, IHttpHandler, etc.), it also includes some Web Forms programming models (pages, contorls, view state, etc ). Do you really want to bring these to your modern lightweight Katana application domain? Yes, the ASP. NET team does not think you will use any of them.

So they created the Helios project. Helios is a prototype project designed to specifically use IIS (using IIS security, cache, process lifecycle management, and so on. drag the Web into your application domain. Helios is a pre-alpha version, so we need to carefully compare it. However, compared with ASP. NET host applications, Helios does prove that it can significantly reduce the memory consumption of request money. It indicates that. NET web tracking will be more concise and scalable in the future. This is a good thing for ASP. NET developers. Now you can study OWIN and Katana. In the end, let the ASP. NET team know that you need an official and complete Helios-like app license!

   3. "Javascript everywhere" of Node is great! Unless it is not

One of the arguments of Node is that you can only use Javascript in your entire application pipeline. This does have many advantages.

Unless your team does not have a full-time JavaScript programmer. Unless you are willing to spend money to recruit tech talents that are currently in high demand in the market. Or, unless you are willing to rewrite your entire application using JavaScript (or you are starting from scratch ...... In this case, you may not have to rewrite it, but you must have the question "Where can I find a full-time JavaScript developer ).

For a more traditional object-oriented language such as C #, it is difficult to master (or master) JavaScript. Prototype inheritance is very powerful, but it is easy to bypass you. The range of variables is "rule". Well, it's also interesting. Forced type conversion, sometimes required, looks very random. "Typeof NaN = 'number '". Believe me, there will be more. Nothing is insurmountable. The productivity of JavaScript is nothing more than that. Something like TypeScript is very helpful, especially for transferring from C # To JS. Just don't expect success overnight.

This is part of the reason. Node is still new to the enterprise level for all fashionable technologies. Of course, some people who like it have been using it for many years (some people in the enterprise are trying to use a fashionable Application Framework ). However, in the short term, if you are looking for talent that can introduce Node on Bigcorp.com, you may need to make some effort. This doesn't mean you don't care about Node ...... However, you must grasp the actual expectations.

In addition, it is important to note that the client-side JavaScript development is the same but completely different from the server-side development. Language differences are not that big (indeed not big), but there is only a small overlap between concepts and patterns. You need to understand not only JavaScript, but also network latency, Asynchronization, server security, scaling, cloud testing and deployment, and efficient data access. Even a good client js developer may not fully understand this. In turn, if your company is just starting to develop. NET, I bet several people in your team know about these things. They may not understand Node (not yet), but they still have the knowledge you can use.

Here we see one problem. No matter how popular JavaScript and Node are. It is important that they apply to your specific situation. Yes. It is very important to think about future technical trends and the "Talent Market" trend ...... But how confident are you in what you know? We can take some training to guess tomorrow ...... But it's what they do, just speculation. A brand new region ...... C # may not be "cool", but it will not disappear soon.

More in the following. So if you like Node, be excited about it and check whether it is suitable for you and your team. But you need to focus on today's needs first and focus less on the next flash of new things you will adopt. It will flash when you are ready.

   4. How can your ASP. NET application be small but slow to respond? Maybe this problem lies in your design.

This difference will prevent you from using Node to rewrite your Web application to fix your current problems in ASP. NET implementation. Node rewriting does not significantly help, and may not help.

This is like adding muja coffee to Indian tea at Ye Ole Software Association will inevitably cause overflow. So turning to Node won't simply solve your problems... the root cause of these problems lies in you, not Microsoft.

Ask yourself (honestly) which of the following statements is appropriate:

1. You and your team are far-sighted and superior software engineers who will use time to identify the best software engineering practices in ASP. NET and apply them to your projects. Your design is SOLID. You can perform unit tests on the modules. You know that your code test covers the standard, and you know why it is not 100%. You can calmly analyze the advantages and disadvantages of Entity Framework, nhib.pdf, native ADO. NET, and millions of micro-ORMs frameworks and make reasonable choices based on your project restrictions. After a long time of hard thinking, you decide how you gather the business logic of your client and server applications, and how the following technologies, tools, productivity, and performance affect your decision-making. You and your partners work hard to simulate real-world use cases and plots, and even set performance levels and load test scenarios early in the project, so you now have charts on performance and scale. You can freely describe your application and data access permissions for countless times. You can also modify them or remove additional features without any difference. It takes time for managers to understand these things, but you need to hand over high-quality code.

2. You and your team are short-sighted and irrational "developers" who are not competent to do their jobs and are desperate to keep their jobs. According to the definition, you have never read about ASP. NET best practice books or articles (if you are reading this article, you can find the best practice materials on Stack Overflow and search for GDD or Google-driven development ). Your design principle is "solid ". Developers who have stayed in your team have written some unit test cases. When some code changes, you have commented on them, these use cases will never be compiled again (although your project manager still references them in the code quality weekly report to the CTO ). Once, you heard from colleagues who have changed three jobs that the physical framework is "bad", and nhib.pdf is "too complicated ", therefore, you can write your own DAL to assemble the SQL statements in the memory (by requesting... no cache), and ensure that your dynamic database fields (ExtraColumn1, ExtraColumn2 ,... ExtraColumn25) read to the appropriate location, based on a record (or... You heard from another colleague that the Entity Framework EF is "great", so you use the EF object graph operation in-depth structure for the entire server architecture, EF object graph ing is a database compatible with the fifth paradigm designed by the "database architect" who has never seen seven tables associated ). You don't know what analyzer is. "SQL Execution Plan" sounds like you are going to jail. You "tested" the system for several months, but never tried to concurrently send user requests. Your scalability is "Buy More Hardware ". And so on.

3. Between 1st and 2nd cases.

To be honest, many of our teams are neither 1st nor 2nd, but between 1 and 2. this is normal. There are no perfect projects or teams in this world. therefore, if you prefer the situation in the above 1st, and improve ASP. NET Performance and scalability, you have done everything you can, and the results are still not satisfactory, so it may be time to switch to other frameworks.

Only incompetent people will push their mistakes to tools. ASP. NET is a modern version that finds bugs in the compiler... The problem may come to your team. of course, I'm not talking about ASP. NET is perfect, and there is no problem at all (in fact, ASP. NET itself ). it is just a tool, a useful tool, and a tool that thousands of websites use every day. some of these websites (or even most of them) are more complex and have a higher access volume than yours. A framework that has been used for many years cannot meet the development requirements of your project. Frankly speaking, it is not big.

Based on different definitions of the word "better", the above points do not mean that Node is better or worse than ASP. NET. It means that if you plan to switch from ASP. NET to Node, this is good, but do not criticize ASP. NET in terms of performance and scalability. Node is not a magic fan in "freely apply for more scalability. Node is just a tool similar to ASP. NET... It works well when used properly. Using it rashly and without a clear understanding of its advantages and disadvantages is like spending a lot of time and money rewriting Node, and eventually returning to the origin is where you are today.

My friend, it's like a pretty sad voice.

   5. Child, "Microsoft is dying! /Broke! /Evil! /Bored! /Earth and earth! /And so on ." It is impossible to develop a technology strategy

Now, as you have read, some people who work in the enterprise software field are switching from ASP. NET to Node because they hate Microsoft for no reason. These people are trustworthy decision makers within their organization. They are responsible for the technical decisions that can generate significant downstream impacts (positive or negative) in business. When you skip their PPT summary page, the first page, or the second page to view the following content, the reason for the failure disappears. Their arguments can almost come down to "I don't like Microsoft, I don't like ASP. NET, I want to do something cool for Young People ".

As of December 31, 2013, the Financial Times (FT) ranked fourth in Microsoft's market value in the top 500 global index. In the same quarter, Microsoft's revenue hit a record of $24.5 billion. Microsoft has not gone bankrupt, far from that. Microsoft Azure is full of vigor and it provides a good positioning for enterprises to continue to migrate to the cloud. In this field, it is competitive, and we are only developing to the initial stage. Compared with traditional Office software, Office 365 has become a feasible cloud computing-based alternative product. Like other companies, Microsoft continues to invest heavily in R & D (how can this be boring ?). Is Microsoft "Rustic? If you ask this question based on the definition of enterprise IT solutions, do you find yourself wrong?

Don't get me wrong... At the beginning of a big new project, there are many reasons to choose other products rather than Microsoft products. Early licensing costs may be unacceptable, especially compared to various open-source software (although there is a way to reduce those costs ). At this point, at least the long-term viability of some of Microsoft's core technologies is unstable. Based on Satya Nadella's promotion to CEO and all his happy public speeches, we still don't know whether he can take advantage of Microsoft's existing advantages and solve Microsoft's problems.

However, if you have invested heavily and significantly established a technical advantage, it is often a mistake to abandon it and start over. Joel wrote this before January 1, 100. In my experience, this is usually a subjective decision, not an objective decision... No matter which technology is discussed.

If you are a CTO, face the legacy ASP. NET code, you think that using Node rewriting will solve all the problems. You are doing a favor for your company, your board of directors, and your customers. They don't give you a salary to make you replace in popular technologies. They didn't pay you either to show you the story of Microsoft soap opera: "which technology is popular this week ?" . "They pay you for commercial value... Predictable economic value and high-quality products. At the beginning, R & D Technologies were chosen less than we wanted to be recognized by others. In a software project, most variability is human-centered. However, when we can criticize our shortcomings, things become much easier, "Everyone knows ASP. NET cannot form a scale".

Let's assume that you are an ASP-based online store, but you are a little worried about over-relying on a single vendor. What solutions do you have to surpass "rewrite all nodes "? First, you can identify part of your architecture, which may benefit from various open-source alternatives and use them to change ASP. NET in the box. For. NET, the main reason why the vibrant open-source ecosystem in the past few years has made it more elegant (mainly ?). The entire framework is great, but can you consider alternative solutions like Massive or Simple. Data? Maybe your data access policy needs to be changed. Will your applications benefit from using NoSQL databases MongoDB or RavenDB? Maybe you have created an appropriate service layer that can take advantage of the new form, as directly as the responsive UI. These types of architecture changes are by no means easy. They are not considered lightweight, but they may need to solve specific problems, but are faced with no larger budget to throw the risk and start over.

Second, consider more radical ideas, such as running on The Mono platform and choosing your own host OS. Currently, ASP. NET and MVC run quite well on Mono. If you are interested in Cloud technology but do not want to use Azure, you have other platforms running ASP. NET... AWS EC2 (Amazon scalable cloud hosting) virtual machines, AWS Elastic Beanstalk (Amazon's PaaS Service), small cloud computing space providers such as AppHarbor, and recently released support. NET's Red Hat OpenShift (cloud computing service platform ).

Finally, determine which technology and platform you have chosen. In addition to the license fee mentioned above, there are many things to consider. The total cost of ownership is not only the upfront cost, but also the cost for use... Some of these costs are not easy to quantify. What is the opportunity cost for your team to perform Node rewriting on time? When ASP. NET application development encounters problems, you can call technical support 24x7 instead of looking for answers on a Node Developer Forum. What is the value for you? In your geographic region, are there more front-end talents such as Node, or are there more mainstream technical experts such as. NET and Java? How difficult is it to find, attract, and retain outstanding Node developers? Are you ready to deal with the problems they may be dug out? At present, many developers of your team have mastered valuable field expertise... When you switch to Node, do you plan to keep these developers? How can we transform our expertise into a new technical architecture? If you plan to stop hiring them, are you sure you are ready to watch them take their hard-won field knowledge out of the company's door?

There is no black or white... Unlike recruiting "outdated" developers: proficient in outdated technologies and not attractive to recruiters, This is a successful recruitment strategy. To put it bluntly, always sticking to ASP. NET (or any other technology) is not like a correct choice. Before you make a major decision from ASP. NET to Node, you must consider all the above factors objectively rather than subjectively. Be cautious and objective.

I hope I have provided you with something to think about. I like Node very much. In the next few years, I plan to spend more time learning it. But I also like ASP. NET... in view of its functions and future plans. It is wise to keep an eye on both of them and not to make decisions too early.

Finally, there is no unique answer to the language selected in different scenarios, but you can refer to some guiding principles. Let's discuss these principles in the next article.