1. ASP.NET MVC 4框架：ASP.NET MVC上的Web应用
建立在 迷你版 ASP NET MVC上的Web应用
在正式介绍我们自己创建的 迷你版 ASP NET MVC的实现原理之前 不妨来看看建立在该框架之上的Web应用如何定义 通过Visual Studio创建一个空的ASP NET Web应用（注意不是ASP NET MVC应用）并不会引用System Web Mvc dll这个程序集 所以在接下来的程序中看到的所谓MVC的组件都是我们自行定义的
首先定义了如下一个SimpleModel类型 它表示最终需要绑定到View上的数据 为了验证针对Controller和Action的解析机制 SimpleModel定义的两个属性分别表示当前请求的目标Controller和Action
public class SimpleModel
{
public string Controller { get; set; }
public string Action { get; set; }
}
与真正的ASP NET MVC应用开发一样 我们需要定义Controller类 按照约定的命名方式（以字符 Controller 作为后缀） 我们定义了如下一个HomeController HomeController实现的抽象类型ControllerBase是我们自行定义的 以自定义的ActionResult作为返回类型的Index方法表示Controller的Action 它接受一个SimpleModel类型的对象作为参数 该Action方法返回的ActionResult是一个RawContextResult对象 顾名思义 RawContextResult就是将指定的内容进行原样返回 在这里我们将作为参数的SimpleModel对象的Controller和Action属性显示出来
public class HomeController: ControllerBase
{
public ActionResult Index（SimpleModel model）
{
string content = string Format（ Controller: { }<br/>Action:{ }
model Controller model Action）
return new RawContentResult（content）
}
}
ASP NET MVC根据请求地址来解析出用于处理该请求的Controller的类型和Action方法名称 具体来说 我们预注册一些包含Controller和Action名称作为占位符的（相对）地址模板 如果请求地址符合相应地址模板的模式 Controller和Action名称就可以正确地解析出来 和ASP NET MVC应用类似 我们在Global asax中注册了如下一个地址让脊模板（{controller}/{action}） 我们还注册了一个用于创建Controller对象的工厂 RouteTable ControllerBuilder和DefaultControllerFactory都是我们自定义的类型
public class Global : System Web HttpApplication
{
protected void Application_Start（object sender EventArgs e）
{
RouteTable Routes Add（ default
new Route{Url = {controller}/{action} }）
ControllerBuilder Current SetControllerFactory（
new DefaultControllerFactory（））
}
}
正如上洞滑旅面所说的 ASP NET MVC是通过一个自定义的HttpMole实现的 在这个 迷你版 ASP NET MVC框架中我纳凳们也将其起名为UrlRoutingMole 在运行Web应用之前 我们需要通过配置对该自定义HttpMole进行注册 下面是相关的配置
<configuration>
<system webServer>
<moles>
<add name= UrlRoutingMole
type= WebApp UrlRoutingMole WebApp />
</moles>
</system webServer>
</configuration>
到目前为止 所有的编程和配置工作已经完成 为了让定义在HomeController中的Action方法Index来处理针对该Web应用的访问请求 我们需要指定与之匹配的地址（符合定义在注册地址模板的URL模式） 如图 所示 由于在浏览器中输入地址（//…/Home/Index）正好对应着HomeController的Action方法Index 所以对应的方法会被执行 而执行的结果就是将当前请求的目标Controller和Action的名称显示出来 （S ）
图 采用符合注册的路由地址模板的地址访问Web应用
上面演示了如何在我们自己创建的 迷你版 ASP NET MVC框架中创建一个Web应用 从中可以看到和创建一个真正的ASP NET MVC应用别无二致 接下来我们就来逐步地分析这个自定义的ASP NET MVC框架是如何建立起来的 而它也代表了真正的ASP NET MVC框架的工作原理
返回目录 ASP NET MVC 框架揭秘
编辑推荐
ASP NET开发培训视频教程
Microsoft NET框架程序设计视频教程
Java程序性能优化 让你的Java程序更快 更稳定
Visual C++音频/视频技术开发与实战
lishixin/Article/program/net/201311/16113
2. .net web api实例应该如何写
由于我机器装的是win8企业版操作系统，VS版本是2012，因此我们选择使用VS自带的MVC4模版中的Web API来创建一个项目。
点击确定后，VS会自动为我们创建一个完整的可运行的ASP.NET Web API的项目。
从项目的目录结构可以看出，ASP.NET Web API与ASP.NET MVC项目的结构几乎一致。我们删除为我们默认创建并打开的ValuesController文件（示例性文件，可以参考）。
既然要打造一个IP地址查询服务接口，为了跟上文的服务形式一致，我们还是使用GET请求方式的服务，不过我们这次使用MVC中的Web API来实现。
首先在Models文件夹中建立一个Address模型类。
?
1
2
3
4
5
6
7
8
9
namespace MvcWebApi.Models
{
public class Address
{
public string IPAddress { get; set; }
public string Province { get; set; }
public string City { get; set; }
}
}
接着我们在Controllers文件夹下建立一个IPAddressController控制器，需要注意的是，这个IPAddressController一定要继承自ApiController类，这样服务才能暴露出来。
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
namespace MvcWebApi.Controllers
{
public class IPAddressController : ApiController
{
private static IList addresses = new List
{
new Address(){ IPAddress="1.91.38.31", Province="北京市", City="北京市" },
new Address(){ IPAddress = "210.75.225.254", Province = "上海市", City = "上海市" },
};
public IEnumerable GetIPAddresses()
{
return addresses;
}
public Address GetIPAddressByIP(string IP)
{
return addresses.FirstOrDefault(x => x.IPAddress == IP);
}
}
}</address></address></address>
只要做上面两步就可以运行这个项目了，我们按Ctrl+F5运行整个项目，出现了如下的页面。
我们点击右上角的API链接。
可以看到我们定义的Web API的接口的使用方法以及说明。
既然是服务，能够被其它程序调用就需要一个持续保障它运行的环境，我们可以将这个写好的Web API的项目发布到IIS当中。
我们可以使用VS自带的发布功能进行发布，并映射到IIS应用程序目录当中。
我们点击IIS右侧的浏览，看看服务有没有能够正常运行。
我们按照文档的提示，我们在地址栏输入http://192.168.0.2/webapi/api/ipaddress。
可以看到，我们收到了Web API定义的服务提供的数据。同样的我们试一下另外一个接口方法。
OK，这样就好了。
但是如果我们需要返回JSON格式怎么办呢？有个简便的方法，在Global.asax.cs文件中，添加一个方法即可。
关于这段代码的原因，可以参考：http://blog.miniasp.com/post/2012/10/12/ASPNET-Web-API-Force-return-JSON-format-instead-of-XML-for-Google-Chrome-Firefox-Safari.aspx，这里不重复。
我们运行这个项目后，重复发布。
当我们再次在浏览器中运行时，就可以看到默认返回的是JSON格式了（IE默认就是JSON）。
ASP.NET Web API就开发好了，至于在C#程序中怎么调用，可以参考我上篇博客中的代码。如果要在页面中调用，可以通过jQuery等JS库请求URL即可。
3. .net中MVC web项目和webapi有啥区别
首先要重点说的是，Web API是一种无限接近于RESTful风格的轻型框架，且不是微软提出来的，微软在.NET上实现了这中框架—http://Asp.Net
Web API，所以“微软包装”是一个极大的偏见。
就应用市场时间而论，MVC普及市场的时间比Web API时间早。为什么MVC提出来了，且都被大家公认是一种经典的web站点实现架构，为什么还要搞Web API呢？
这两年什么炒得最火热？互联网。在网络技术不断更新和替代的过程，网络不断普及。互联网产品只要你有技术，就可以做。但要说明的是，互联网产品的用户不再是一小部分人群，除了潜在用户，你需要面对的是庞大的上网人群和开发者。这时候你要考虑你的WEB服务器是否能够支持这么多的用户，节省一点点传输数据的带宽都能够让你的服务器轻松不少，除此之外，你还要考虑你的潜在用户变成你的真实用户的某刻时刻，你的服务器是否能够顺利支撑。
面对用户，你要考虑你的产品是否能够让用户使用起来感觉很“爽”，你要把用户体验放在首位，那么你的产品首先功能上必须稳定，不然即使有再好的创意，再耐心的用户总会使用其它产品替代你的产品。
面对开发者，你想要把某些功能开放，这时候你必须要开放某些接口。有人会说，我也可以使用MVC来开放这些接口，没错是可以，但是绕远道给你带来的是更大的代价。
Web API 和 MVC可以说是两个不同的东西。Web API更倾向于基于HTTP协议的服务，直接返回用户的数据请求。MVC是建站的一种框架，倾向于返回用户的页面请求。
我总结了以下 http://ASP.NET Web API 的特性，更能说明Web API是一种数据请求框架：
http://ASP.NET
Web API 可以根据请求报文来返回的相应数据格式。包括JSON和XML。http://ASP.NET
Web API 单独做数据请求和MVC做页面请求可以让Web前端和后台更好的解耦，减少开发难度。Web API 可以更好地用在移动端网页、桌面端网页或者桌面程序。
Web API 的宿主可以选择多样：WebHost,，ConsoleHost，甚至是windows Services。
类似可以理解成ashx和webform的区别
4. asp.net mvc3 项目怎么开发API接口
Visual Studio为我们提供了专门用于创建ASP.NET Web API应用的项目模板，借助于此项目模板提供的向导，我们可以“一键式”创建一个完整的ASP.NET Web API项目。在项目创建过程中，Visual Studio会自动为我们添加必要的程序集引用和配置，甚至会为我们自动生成相关的代码，总之一句话：这种通过向导生成的项目在被创建之后其本身就是一个可执行的应用。
对于IDE提供的这种旨在提高生产效率的自动化机制，我个人自然是推崇的，但是我更推荐读者朋友们去了解一下这些自动化机制具体为我们做了什么？做这些的目的何在？哪些是必需的，哪些又是不必要的？正是基于这样的目的，在接下来演示的实例中，我们将摒弃Visual Studio为我们提供的向导，完全在创建的空项目中编写我们的程序。这些空项目体现在如右图所示的解决方案结构中。
如右图所示，整个解决方案一共包含6个项目，上面介绍的作为“联系人管理器”的单页Web应用对应着项目WebApp，下面的列表给出了包括它在内的所有项目的类型和扮演的角色。
·Common：这是一个空的类库项目，仅仅定义了表示联系人的数据类型而已。之所以将数据类型定义在独立的项目中，只要是考虑到它会被多个项目（WebApi和ConsoleApp）所使用。
WebApi：这是一个空的类库项目，表现为HttpController类型的Web API就定义在此项目中，它具有对Common的项目引用。
WebHost：这是一个空的ASP.NET Web应用，它实现了针对ASP.NET Web API的Web Host寄宿，该项目具有针对WebApi的项目引用。
SelfHost：这是一个空的控制台应用，旨在模拟ASP.NET Web API的Self Host寄宿模式，它同样具有针对WebApi的项目引用。
WebApp：这是一个空的ASP.NET Web应用，代表“联系人管理器”的网页就存在于该项目之中，至于具体的联系人管理功能，自然通过以Ajax的形式调用Web API来完成。
ConsoleApp：这是一个空的控制台应用，我们用它来模拟如何利用客户端代理来实现对Web API的远程调用，它具有针对Common的项目引用。
二、定义Web API
在正式定义Web API之前，我们需要在项目Common中定义代表联系人的数据类型Contact。简单起见，我们仅仅为Contact定义了如下几个简单的属性，它们分别代表联系人的ID、姓名、联系电话、电子邮箱和联系地址。
1: public class Contact
2: {
3: public string Id { get; set; }
4: public string Name { get; set; }
5: public string PhoneNo { get; set; }
6: public string EmailAddress { get; set; }
7: public string Address { get; set; }
8: }
表现为HttpController的Web API定义在WebApi项目之中，我们一般将ApiController作为继承的基类。ApiController定义在“System.Web.Http.dll”程序集中，我们可以在目录“%ProgramFiles%\Microsoft ASP.NET\ASP.NET Web Stack 5\Packages\”中找到这个程序集。具体来说，该程序集存在于子目录“Microsoft.AspNet.WebApi.Core.5.0.0\lib\net45”中。
Web API体现在如下所示的ContactsController类型中。在该类型中，我们定义了Get、Post、Put和Delete这4个Action方法，它们分别实现了针对联系人的查询、添加、修改和删除操作。Action方法Get具有一个表示联系人ID的可缺省参数，如果该参数存在则返回对应的联系人，否则返回整个联系人列表。由于ASP.NET Web API默认实现了Action方法与HTTP方法的映射，所以方法名也体现了它们各自所能处理请求必须采用的HTTP方法。
1: public class ContactsController: ApiController
2: {
3: static List<Contact> contacts;
4: static int counter = 2;
5:
6: static ContactsController()
7: {
8: contacts = new List<Contact>();
9: contacts.Add(new Contact { Id = "001", Name = "张三",
10: PhoneNo = "0512-12345678", EmailAddress = "[email protected]",
11: Address = "江苏省苏州市星湖街328号" });
12: contacts.Add(new Contact { Id = "002", Name = "李四",
13: PhoneNo = "0512-23456789", EmailAddress = "[email protected]",
14: Address = "江苏省苏州市金鸡湖大道328号" });
15: }
16:
17: public IEnumerable<Contact> Get(string id = null)
18: {
19: return from contact in contacts
20: where contact.Id == id || string.IsNullOrEmpty(id)
21: select contact;
22: }
23:
24: public void Post(Contact contact)
25: {
26: Interlocked.Increment(ref counter);
27: contact.Id = counter.ToString("D3");
28: contacts.Add(contact);
29: }
30:
31: public void Put(Contact contact)
32: {
33: contacts.Remove(contacts.First(c => c.Id == contact.Id));
34: contacts.Add(contact);
35: }
36:
37: public void Delete(string id)
38: {
39: contacts.Remove(contacts.First(c => c.Id == id));
40: }
41: }
简单起见，我们利用一个静态字段（contacts）表示存储的联系人列表。当ContactsController类型被加载的时候，我们添加了两个ID分别为“001”和“002”的联系人记录。至于实现联系人CRUD操作的Action方法，我们也省略了必要的验证，对于本书后续的演示的实例，我们基本上也会采用这种“简写”的风格。
5. Web Api及MVC性能提升的几个小技巧
一、缓存
为了避免每次请求都去访问后台的资源，我们一般会考虑将一些更新不是很频繁的，可以重用的数据，通过一定的方式临时地保存起来，后续的请求根据情况可以直接访问这些保存起来的数据，这种机制就是所谓的缓存机制。缓存分为页面输出缓存，内存数据缓存和缓存依赖等。从设计原则来说，易变性、敏感性的信息不适合进行缓存，同时缓存的内容也是易丢失的，在代码中不能完全依赖于缓存的数据，需要保证在缓存的数据丢失后也能进行正确的处理。
1、页面输出缓存
通过对输出的页面进行缓存，每次新的用户请求调用相同的 Action 时，相同的内容不需要重新创建一次而直接输出。页面输出缓存的使用非常简单，在 Action 上使用 [OutputCache] 特性标记即可生效。页面输出缓存可控制缓存的内容所存储的位置，例如是在服务器端存储缓存的页面内容还是在客户端存储缓存的页面内容；也可使用 Duration 参数控制缓存的失效绝对时间和间隔时间，甚至能使用 VaryByParam 参数对不同的请求参数分别进行缓存。页面输出缓存非常适合于内容比较固定的前端页面的缓存。
2、内存数据缓存
通常情况下，数据是保存在数据库、磁盘文件等存储介质中的，而应用程序访问这些资源是一项很费时的操作。如果先将这些资源中的数据缓存到内存缓存区中，当应用程序需要这些数据时，直接从缓存区中提取，就可以减少系统开销，显着提高可使用的用户并发数等。内存数据缓存需考虑缓存的内容更改失效后如何清空其他已经被缓存的相关联的数据问题。
3、EFCache
众所周知，NHiberate 提供了二级缓存功能。现在，如果你使用的是 Entity Framework 6 或更高版本的 Entity Framework ，你也可考虑使用 EFCache 组件来为 Entity Framework 提供二级缓存支持，其实质上也是属于内存数据缓存。EFCache 的特点是使用上非常方便，仅需定义如下的代码无需其他复杂的额外的配置即可实现二级缓存。如需定义特定的缓存策略，如缓存的过期时间，控制数据缓存的范围，也仅需继承 CachingPolicy 类并 override 其部分方法即可。你甚至可以通过实现 ICache 接口来实现自定义的缓存模型以替换默认的 InMemoryCache 。
二、Stream压缩
对响应流进行压缩，其作用是减少网络开销，提高系统的响应速度。目前的浏览器通常都支持 gzip 和 deflate 压缩解压功能，因此你通常无效考虑浏览器的兼容性问题。启用 gzip 和 deflate ，既可通过 IIS 配置实现，在 MVC 中也可通过编写自定义的 ActionFilter 实现。在压缩之前和压缩之后 Stream 的大小差异通常都是惊人的，其压缩率通常都在5-10倍以上。
三、js和css文件的压缩和打包
1、js 和 css 文件的压缩
其实质就是生成较小的文件，减小下载这些文件的网络开销，提供系统的响应速度。压缩 js 和 css 文件还有个好处是通常还可以起到代码混淆的作用。在 YbSoftwareFactory 的 MVC 解决方案中，使用的是 Microsoft Ajax Minifier 组件，可在代码编译的过程中自动对所配置的 js 和 css 进行压缩，基本上文件的大小都可减少一半以上
2、js、css文件的打包
其目的是进行 js 文件和 css 文件的合并，当前主流浏览器的并发连接数默认情况下通常都是 6 个，如果前端页面同时请求的服务器资源（如 img 文件、js 文件、css 文件以及各类 url 请求等）超过6个，通常就需要进行排队下载。进行 js 文件、css 文件的打包合并，通常可以在一次请求中就完成未打包之前需多次请求才能完成的工作，通过减少前端浏览器的连接请求，在某种意义上也是可提高系统的响应速度的。
6. 基于ASP.NET MVC框架开发Web论坛应用程序[1]
我想通过本系列文章从头到尾构建一个完整的ASP NET MVC论坛应用程序 最终的目的是探讨和推动使用ASP NET MVC框架构建应用程序的最佳实践友局
简介
在本篇中 我想先从全局方面介绍一下论坛应用程序的总体目标 在本篇中 我将讨论一下避免代码坏味道的重要性 还将讨论如何利用软件设计原则和模式来帮助你编写适合未来改变的富有弹性的代码 最后 我还将论证一下为什么我选择使用测试驱动开发方式构建本系列文章中的论坛应用程序
什么样的软件是好的软件
我不想仅仅为了构建论坛应用程序而任意构建此论坛应用程序 我的目标是尽可能构建最棒的论坛应用程序
这个目标立即引发这样一个问题 什么样的软件是好的软件？是什么导致一个应用程序比另一个应用程序更好一些或更差一些呢？在事先没有一个关于 好软件 的定义之前 我无法声明我构建了一个完美的论坛应用程序
因此 下面是我对于 好软件 的定义
好软件是设计得易于修改的软件
存在多种原因可能需要你改变软件
)你可能需要在一个现有软件上添加新的特征 )你可能需要修改一个现有软件中的错误 )你可能需要优化现有软件 )你可能需要改进现有软件的设计
一般说来 设计糟糕的软件是难于改变的 有些软件设计得如此糟糕 以致于每个人都害怕碰一碰它 我们大家应该都使用过设计得糟糕的软件 当软件不好时 你很希望它干脆走开 甚至如果有机会的话 你可能想从头开始重新编写这款软件
避免代码坏味道
Robert和Micah Martin把糟糕的软件部分描述为代码坏味道 下列代码坏味道意味着此软件的书写是相当糟糕的
)僵化性（Rigidity）—僵化的软件是这样的软件 当你在某个位置作一改动时即要求对系统作出相应的一系列的更改 )脆弱性（Fragility）—脆弱的软件是这样的软件 你在某个好锋让位置作一改动时即打断另外多处的正常运行 )不必要的复杂性—不必要的复杂软件是指过度设计的软件 其目的是为了处理任何可能的改变 )不必要的重复—不必要的重复软件中包含大量的重复性代码 )晦涩性—晦涩的软件是指难于理解的软件
【注意】上述这些代码味道在Micah和Robert Martin的着名《Agile Principles Patterns and Practices in C#》中得到充分的描述 在此 强烈建议读者读一下这本书 注意 上述这些代码味道都与所有的代码改变相关联 每一个这些代码味道都将妨碍代码的改变
软件设计原则
遵循良好的软件设计原则 将有助于编写软件易于适应未来更改的软件 软件设计原则有若干 也不尽相同 例如 Cunningham和Cunningham Wiki描述面向对象设计的 个原则 //c /cgi/wiki?
其中提到的面向对象设计的前五个原则与Robert Martin及他的儿子Micah Martin编着的《Agile Principles Patterns and Practices in C#》中所基激主张的软件设计原则是一致的 此外 Robert Martin还在Object Mentor开辟的博客上讨论了这些原则 // objectmentor /resources/publishedArticles
此外 我还发现有另外两本书中也提供了有关软件设计原则的极其有用的信息 第一本是Eric Freeman Elisabeth Freeman Kathy Sierra Bert Bates编着的《Head First Design Patterns》 第二本是Brett McLaughlin Gary Pollice和David West编着的《Head First Object Oriented Analysis and Design》 尽管这些书所讨论的原则与Robert Martin的提法并不十分相同 但是它们却十分相近
lishixin/Article/program/net/201311/14493
7. 如何使用mvc实现webapi的增删改查
1.创建项目：visual C# —> ASP.NET MVC 4 web应用程序 模板—>web api;
2.注册路由:
路由表中的每一个条目都包含一个路由模板。这个Web API默认的路由模版是"api/{controller}/{id}"。在这个模版中，“api”是一个文字式路径片段，而{controller}和{id}则是占位符变量。
当Web API框架接收一个HTTP请求时，它会试图根据路由表中的一个路由模板来匹配其URI。如果无路由匹配，客户端会接收到一个404（未找到）错误。
3.linq to sql连接数据库
1.建立数据库建表
2.在models文件夹里面新建linq to sql类文件
3.工具->连接到数据库
4.将要用的表拖入设计区
5.获取数据库Getway。"linq to sql class"文件名+Datacontext实例化这个对象，数据表就会映射到一个集合属性中，personDataDataContext db = new personDataDataContext();
6.增删改查
增：
public Boolean Post([FromBody]UserInfo userInfo) {
personDataDataContext db = new personDataDataContext();
var s1 = new test2
{
UserName =userInfo.UserName, Id=userInfo.Id, Age=userInfo.Age
};
if (db.test2.SingleOrDefault<test2>(s => s.Id == userInfo.Id) == null)
{
db.test2.InsertOnSubmit(s1);
db.SubmitChanges();
return true;
} else {
return false;
}
}
删:
public bool Delete(int id)
{
personDataDataContext db = new personDataDataContext();
var deleteperson = db.test2.SingleOrDefault<test2>(s => s.Id == id);
if (deleteperson == null)
{
return false;
} else {
db.test2.DeleteOnSubmit(deleteperson);
db.SubmitChanges();
return true;
}
}
改:
public Boolean Put(int id, [FromBody]UserInfo userInfo)
{
personDataDataContext db = new personDataDataContext();
var editperson = db.test2.SingleOrDefault<test2>(s => s.Id == userInfo.Id);
if (editperson == null)
{
return false;
} else {
editperson.Age = userInfo.Age;
editperson.UserName = userInfo.UserName;
db.SubmitChanges();
return true;
}
查:
public IEnumerable<test2> Get()
{
personDataDataContext db = new personDataDataContext();
var query = from s in db.test2
orderby s.UserName
select s;
return query;
}
// GET api/values/5
public string Get(int id)
{
return "value";
}
这里我新建了一个userinfo类
public class UserInfo { public string UserName { get; set; } public int Id { get; set; } public int Age { get; set; } }
用来接收前端页面ajax请求中的data数据，s => s.Id == userInfo.Id是lamda表达式创建委托方法意思是在db.test2的person集合中查找某个person的Id与userinfo接收到的id相等的person对象
8. 如何看待asp.netweb开发技术
先简单回顾下asp.net过去十年
mvc流行前
asp.net的服务端控件，将html和js一起封装，很多客户端事件自动通过生成的js将数据重新post回服务端。而对于很多刚入门的小伙伴来说，仅仅靠拖放控件和写C#代码就可以实现一个可用的Web项目，大大降低了入门门槛。相应的，服务端控件这种过度耦合的设计带来了很多缺点：自定义控制难，难以纯粹将前后端分离，导致asp.net从业人员既不能精通困神前段技术，又不能涉猎更多的后端技术（生态问题）。
这个年代，.net被贴上了“拖放控件”的标签。
mvc流行后
微软推出了asp.netmvc，很多公司已经开始尝试前后端分离。就模式上面来说，已经和其它语言平台基于mvc的web项目开发模式无异。
但是asp.net本身的服务框架太杂乱，尤其是艰难（如果你留意过，甚至可以说难产）支持asyncawait异步编程后，他的同步上下文模型缺点太大：首先是源码的结构混乱，其次是使用过程很多人容易造成死锁，异步方法使用不当导致请求已返回上下文已释放然后找不到同步对象导致的异常。问题的根源是大部分程序员对线程了解不深，如果项目有正确的规范用法还好，一旦没有，产生异常很多人根本不知道问题出在哪里。博客园改造过程中就哗尺桐出现过的死锁，有兴趣的可以去看看博客园官方博客写过。
aspnetcore
新应用程序模型设计和代码实现，我非常喜欢。其它的不说，看看那简洁的Reqeust和Response对象，是不是就会让你欣喜？再看看中间件管道，上下文（Context）通过委托链链一路传递，再也不用晦涩的同步上下文，也移除了和Windows安全相关的特征。
整个架构更加清晰，喜欢做扩展的人绝对会有一日看尽长安花的快感。
自然性能也不用说，可以关注github上乱坦微软之前做过的除了mvc之外的性能测试对比。
net生态
拥抱开源后，netcore，standard，aspnetcore，efcore等一系列实现全部都有了，明年的netcore3.0还会包含客户端模型（wpf和winform，只能在windows下使用）。
github上面aspnet，dotnet，dotnet-architecture等分支包含大量微软直接维护的开源项目。
开源社区大部分的项目已经跟进将三方组件基于standard标准打包。
微软也久违地把散乱的文档汇集到docs子域名下
万事剧本，就欠生态！如果apache基金会下面的重要项目都有.net的分支，相信依靠netcore必定可以再次抢占不少的份额。
前景
微服务流行后，其实内部可以混合多种平台提供服务，用aspnetcore做对三方组件需求不太大的业务服务是完全的可以的，基于微软一贯的作风，开发效率是很高的。
其实现在很多内部系统在用.net，只是面向互联网相关的项目，更加需求丰富的三方资源，采用.net的比较少。不过很多大的公司都有.net的分支团队。毕竟在桌面和开发效率上的优势，还是有他存在的价值。
aspnet到底会如何发展，个人感觉还是要看社区的反应，要看生态是否能逐步丰富起来。
看在微软这么努力的份上，个人挺希望他能够扳回一局。
所以？
眼光放长远一点，平台只是我们的工具，一个IT人不应当把自己的技术范围限定到某一个平台。多学多积累，实际项目中应该针对需求、架构以及团队做出选择。
比如Java和.net同时掌握，各取所长，基于他们重叠性较高的原因，学习成本并不高。何况绝大部分的知识和平台并无关系。
个人见解纯手打，欢迎大家评论或者提出意见。