ASP.NET编程：办理Entity Framework中年夜数据模子成绩的技能仓酷云

就安全性而言，net网页编程已经远远低于VB.NET，更无法与安全性著称的C#相比。EntityFramework的开辟向导SrikanthMandadi称这个包括两部份内容的文章为“办理EntityFramework中的年夜数据模子成绩”，但很分明它的寄义为“利用一些技能”来办理这些成绩。该文章起首谈到了不管对任何使用来讲，希冀的实体数目在50到100之间。超越这个局限会招致编纂器没法利用。
EntityFramework有一些严峻的功能成绩。比方，每次利用一个新的毗连字符串时，针对全部数据模子的基于XML的元数据城市被加载到内存中。假如你有一些共享通用数据模子的小型使用，那末向个中任何一个增添新的实体城市招致一切使用变慢。从实质下去说，这类限定使得我们没法将EntityFramework的数据模子放到共享库中。
视图的天生是EntityFramework计划上的另外一个败笔的地方。SrikanthMandadi注释到：

当查询或是SaveChanges第一次产生时，这个历程就入手下手了。视图天生步骤的功能不但取决于模子的巨细，还与模子之间的接洽有关。假如两个实体经由过程一个承继链或是Association毗连起来，我们就称其为毗连的。与此相似，假如两张表经由过程一个外键毗连起来，我们也称其为毗连的。跟着实体和Schema中表的毗连数目的增加，视图天生的价值就愈来愈年夜了。

为懂得决这些成绩，SrikanthMandadi倡议将年夜的数据模子分别为小的子集。有两种体例能够做到这一点，但感到都不怎样。
第一种仅仅是利用完整自力的子集。假如两个或多个子集都必要某张表，那末就为他们分离创立自力的实体。这类体例招致跨子集的间接挪用没法完成，也简单招致实体的过分收缩。
另外一种体例是“利用”Schema中的语法。IDE不撑持这么做，必要我们手工编纂XML以申明数据库必要利用另外一个数据模子中的实体。除手工编纂XML的疾苦外，它只能创立单向的毗连。假如数据模子A利用了数据模子B中的实体，那末后者将没法援用前者。
你能够在ADO.NET团队的博客上浏览该文章第一部分和第二部分的一切内容。

检察英文原文：WorkingAroundEntityFramework"sLargeDataModelIssues
本文出自：http://www.infoq.com/cn/news/2008/12/EF-Large

我之所以想学。NET，是因为一直觉的BILLGATES好厉害，希望有一天能去微软，虽然现在还距离遥远，呵呵:)

目前在微软的.net战略中新推出的ASP.net借鉴了Java技术的优点，使用CSharp(C#)语言作为ASP.net的推荐语言，同时改进了以前ASP的安全性差等缺点。但是，使用ASP/ASP.net仍有一定的局限性，因为从某种角度来说它们只能在微软的WindowsNT/2000/XP+IIS的服务器平台上良好运行（虽然像ChilliSoft提供了在UNIX/Linux上运行ASP的解决方案.

业务逻辑代码都不必做任何改动；继承性和多态性使得代码的可重用性大大提高，你可以通过继承已有的对象最大限度保护你以前的投资。并且C#和C++、Java一样提供了完善的调试/纠错体系。

大哥拜托，Java在95年就出来了，微软垄断个妹啊，服务器市场微软完全是后后来者，当年都是Unix的市场，现在被WindowsServer和Linux抢下大片，包括数据库也一样。

对于中小项目来说.net技术是完全可以胜任，但为什么现在大型公司或网站都选择php或java呢？就是因为微软不够开放，没有提供从硬件到应用服务器再到业务应用的整套解决方案。

微软又推出ASP.NET。这不是ASP的简单升级，而是全新一代的动态网页实现系统，用于一台WEB服务器建立强大的应用程序。是微软发展的新体系结构.NET的一部分，是ASP和.NET技术的结合。

ASP.net的速度是ASP不能比拟的。ASP.net是编译语言，所以，当第一次加载的时候，它会把所有的程序进行编译(其中包括worker进程，还有对语法进行编译，形成一个程序集)，当程序编译后，执行速度几乎为0。

代码逻辑混乱，难于管理：由于ASP是脚本语言混合html编程，所以你很难看清代码的逻辑关系，并且随着程序的复杂性增加，使得代码的管理十分困难，甚至超出一个程序员所能达到的管理能力，从而造成出错或这样那样的问题。

可以看作是VC和Java的混合体吧，尽管MS自己讲C#内核中更多的象VC，但实际上我还是认为它和Java更象一些吧。首先它是面向对象的编程语言，而不是一种脚本，所以它具有面向对象编程语言的一切特性。