模型元素之间的连接关系有：关联Association、概化Generalization、依赖Dependency、实现Realization、聚合Aggregation、组合Combination。其中，聚合和组合是关联的一种特殊形式。
（1）关联Association：用于描述模型元素之间的连接，只要两个模型元素之间存在相互通信的关系，它们之间就存在关联关系。
关联关系可以是单向的，但一般为双向的。
（2）概化Generalization：又称继承，指一个模型元素的所有信息能被另一个模型元素继承。
继承了其它模型元素的模型元素中不仅可以拥有属于自己的信息，而且还拥有了被继承模型元素中的信息。
（3）依赖Dependency：描述两个模型元素之间语义上的连接关系，其中一个模型元素是独立的。另一个是非独立的。
在这种联系中，改变独立元素将影响到非独立元素的语义。
（4）如果模型元素之间的关系具有“整体与部分”的特点，则这种关联称为聚合或组合。
聚合关系用Has a句型表示，组合关系用Be a part of句型表示。
（5）实现Realization：用于表示同一事务的两种描述之间的关系

• 如果你确定两件对象之间是is-a的关系，那么此时你应该使用继承；比如菱形、圆形和方形都是形状的一种，那么他们都应该从形状类继承而不是聚合。

  如果你确定两件对象之间是has-a的关系，那么此时你应该使用聚合；比如电脑是由显示器、CPU、硬盘等组成的，那么你应该把显示器、CPU、硬盘这些类聚合成电脑类，而不是从电脑类继承。

  类间的关系

  网上关于此类的讨论非常多，发现对于该问题的理解各有各的说法，而各个说法中又相去甚远。通过浏览这些讨论以及对《O'Reilly - UML 2.0 In A Nutshell (2007)》的参考，发表一下自己的看法

  类间关系有很多种，在大的类别上可以分为两种：纵向关系、横向关系。

  纵向关系就是继承关系，它的概念非常明确，也成为OO的三个重要特征之一，这里不过多的讨论。

  横向关系较为微妙，按照UML的建议大体上可以分为四种：

  1. 依赖    （Dependency）
  2. 关联    （Association）
  3. 聚合    （Aggregation）
  4. 组合    （Composition）

  它们的强弱关系是没有异议的：依赖 < 关联 < 聚合 < 组合

  然而它们四个之间的差别却又不那么好拿捏，需要好好体会。

  1. 依赖 （Dependency）：
     • UML表示法：虚线 + 箭头 
       
     • 关系："A uses a B"
     • 编程语言中体现为局部变量、方法的参数或者对静态方法的调用。
     • 此关系最为简单，也最好理解，所谓依赖就是某个对象的功能依赖于另外的某个对象，而被依赖的对象只是作为一种工具在使用，而并不持有对它的引用。
     • 典型的例子很多，比如：
       class Human
       {
           public void breath()
           {
               Air freshAir = new Air();
               freshAir.releasePower();
           }
           public static void main()
           {
               Human me = new Human();
               while(true)
               {
                   me.breath();
               }
           }
       }
       
       class Air
       {
           public void releasePower()
           {
               //do sth.
           }
       }
        
     • 释义：一个人自创生就需要不停的呼吸，而人的呼吸功能之所以能维持生命就在于吸进来的气体发挥了作用，所以说空气只不过是人类的一个工具，而人并不持有对它的引用。
  2. 关联 （Association ）：
     • UML表示法：实线 + 箭头 
       
     • 关系：" A has a B"
     • 所谓关联就是某个对象会长期的持有另一个对象的引用，而二者的关联往往也是相互的。关联的两个对象彼此间没有任何强制性的约束，只要二者同意，可以随时解除关系或是进行关联，它们在生命期问题上没有任何约定。被关联的对象还可以再被别的对象关联，所以关联是可以共享的。
     • 在编程语言中，关联关系是通过使用成员变量来实现的。
     • 典型的例子很多，比如：
       class Human
       {
           ArrayList friends = new ArrayList();
           public void makeFriend(Human human)
           {
               friends.add(human);
           }
           public static void main()
           {
               Human me = new Human();
               while(true)
               {
                   me.makeFriend(mySchool.getStudent());
               }
           }
       } 
       
     • 释义：人从生至死都在不断的交朋友，然而没有理由认为朋友的生死与我的生死有必然的联系，故他们的生命期没有关联，我的朋友又可以是别人的朋友，所以朋友可以共享。
     • 关联的方向：双向关联(association，----------)通过A对象可以找到B对象，B对象同样可以找到A对象的关联为双向关联。 单向关联(direction-association，-------->)通过A对象可以找到B对象，但通过B对象不能找到A对象的关联为单向关联。 

需求分析
　　在具体的研究需求分析之前，我们先了解一下软件工程这个概念。软件工程分为三个层次，过程层、方法层、工具层。在最基础的过程层，最重要的就是一组被称为关键过程区域（KPAs）的框架（KPA的概念在讨论CMM的书中有详细的概念说明）。关键过程区域构成了软件项目的管理控制的基础，并且确立了上下文各区域的关系，其中规定了技术方法的采用、工程产品的，模型、文档、数据、报告、表格等，等的产生、里程碑的建立、质量的保证及变化的适当管理。方法层主要是过程在技术上的实现。它解决的问题是如何做。软件工程方法涵盖了一系列的任务：需求分析、设计、编程、测试、维护。同时他还包括了一组基本原则，控制了每一个的关键过程区域。工具层就很好理解了，他对过程层和方法层提供了自动和半自动的支持。这些辅助工具就称为CASE。
　　可以看到需求分析的位置，但是事实上需求分析是跨越了软件工程的三个层次的。这一点是和其他的过程是一样的。当然我们这里比较重点强调的是在软件工程的方法层，同时也涉及到一些过程层的思想，至于工具层则不再我们的讨论之列，但是会提到一些很适合在需求分析时应用的工具，诸如Word、Excel、Visio等。
方法
　　需求分析都包括了哪些方法呢？这里列举出在《需求分析》一书中推荐的一些方法，
　　1) 绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。
　　2) 创建用户接口原型，当开发人员或用户不能确定需求时，开发一个用户接口原型—一个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。
　　3) 分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。 　　4) 确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
　　5) 为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
　　6) 创建数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。
　　7) 使用质量功能调配，（QFD）是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。QFD将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备（Zultner 1993;Pardee 1996）。
　　记住一点，不要试图在你的项目中把这些方法都用上去，四个现代化并不是一夜就可以实现的。同样，尝试着使用你认为对你很有帮助的方法，确实收到效果之后，在考虑继续学习方法。因为上面提到的都是需求分析的大方法，事实上还有很多很多的方法可以采用，例如，采用SRS模板、指明需求的来源、为每项需求注上标号、记录业务规范、创建需求跟踪能力矩阵、审查需求文档、以需求为依据编写测试用例、编写用户手册、确定合格的标准。
业务建模
　　很多人都没有意识到业务需求阶段应该做些什么事情，实际上业务建模是最重要的一件事情。不要觉得业务建模这个词很深奥，让人模不着头脑。其实所有做过需求分析的人都做过业务建模，比如你了解企业的运作模式就?是一种你脑海中的业务建模。但是大多数人都没有科学的、系统的、文档化的做过业务建模。
　　业务建模的目的在于：
　　了解目标组织（将要在其中部署系统的组织）的结构及机制。
　　了解目标组织中当前存在的问题并确定改进的可能性。
　　确保客户、最终用户和开发人员就目标组织达成共识。
　　导出支持目标组织所需的业务需求。
　　上面的话是不是很抽象呢，其实没有什么复杂的：人和电脑是完全不同的思想（思维方式）。所以，原先适合人的业务流程对于计算机来说可不一定合适的，为了最大限度的利用计算机，必须要了解原先的业务流程并对此加易改造（流程自动化），当然这些动作需要得到用户的许可。有些人认为说只有ERP这种大系统才需要对业务流程进行重组，但是实际上，不论是部门级的MIS系统，还是社会级的电子商务系统，都需要对业务流程进行改造，所不同的只是改造的程度。
　　业务建模很重要的一点是在分析企业流程的同时分析出基础企业对象（Common Business Object）（这个词我翻译的不好，如果大家有更好的翻译，请告诉我）。任何企业都有最基础的一些元素，例如银行的CBO就有帐户，制造业的CBO就有订单等。有一次我的一个在企业应用方面研究多年的朋友告诉我一个秘诀，他说，企业的CBO无非是4个：客户、员工、产品和供应商（银行的供应商应该称为同业）。其他的所有CBO都是在这四个CBO的基础上发展起来的。比如说CBO中客户和产品是多对多的关系，根据关系数据的理论，任何多对多的关系都可以拆分成多个一对多或一对一的关系。你就可以在这两个类之间引入订单类，客户和订单之间是一对多，订单和产品之间又是一对多，这样一个多对多的关系就拆分成两个一对多的关系，而新的订单类也就顺理成章的产生了。在订单类产生时，你可能还会加入一个关联类：业务员类。而业务员类又是从员工类继承下来的。所以呢，企业的四种CBO通过不同的组合，不同的关系，能够形成企业运作的许许多多的CBO。
　　CBO是做业务建模的基础，在此基础上，通过评估业务状态，说明当前业务，确定业务流程，改进业务流程的定义，设计业务流程实现，改进角色和职责，研究流程自动化，开发领域模型等一系列在RUP中定义的工作流程实现业务建模的目标。
需求获取
　　需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。获取用户需求位于软件需求三个层次的中间一层。业务需求决定用户需求，它描述了用户利用系统需要完成的任务。从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系（分析）。然后，你可以使客户信息结构化，并编写成文档和示意图（说明）。下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。这四个过程贯穿着需求分析的整个阶段。 需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级?，以避免一个不能带来任何益处的无限大的项目。 需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本。作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充（open-ended）的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发和利用。
　　还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户是如何想的？询问问题时，以“还有什么能” ,”当?时，将会发生什么”“你有没有曾经想过” ,“有没有人曾经”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的客户。
　　有些时候，尝试着问一些“愚蠢”的问题也有助于客户打开话匣子。如果你直接要求客户写出业务是如何实现的，客户十有八九无法完成。但是如果你尝试着问一些实际的问题，例如：“以我的理解，你们收到订单后，会...”。客户立刻就会指出你的错误，并滔滔不绝的开始谈论业务，而你，就在一边仔细的聆听吧。这一招就叫做“抛砖引玉”。
　　需求讨论会上必须要使用笔记本电脑，还要指定一个打字熟练的人把所有的讨论记录下来，记录的同时还要做一定的整理。如果不这样做，那么你结束会议的时候就会发现，所有的讨论只剩下一个模糊的印象，需求对你来说仍然是一件遥远的事情。在座谈讨论之后，记下所讨论的条目(item)，并请参与讨论的用户评论并更正。及早并经常进行座谈讨论是需求获取成功的一个关键途径，因为只有提供需求的人才能确定是否真正获取需求。进行深入收集和分析以消除任何冲突或不一致性。
　　尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。Gause 和Weinberg（1989）提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。
　　需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式（Kiel and Carmel 1995）。与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。直接聘请用户进行获取需求的过程是为项目获得支持和买入（buy-in）的一种方式。
　　尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。
　　在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。当前的范围太小，以致不能提供一个令人满意的产品。需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。 正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。这样说虽然很简洁，但似乎过于简单化。需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。你可以使用假设“怎么做”来分类并改善你对用户需求的理解。在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。 需求获取讨论会中如果参与者过多，就会减慢进度。人数大致控制在5到7人是最好的。这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。最?好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。 没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的构思。你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。
　　1. 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总是按其重要性的顺序来确定使用实例的。
　　2. 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。这些新的使用实例可能是你已获取的其它使用实例的可选过程。 　
      3. 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。
　　4. 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。
　　5. 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。
　　以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是成功的。

.NET MVC Models定义字段过程中的验证属性参数：

[Required()]

指定数据字段值是必需的。

包含参数：

ErrorMessage 验证失败的错误消息；

ErrorMessageResourceType 错误消息资源类型；

ErrorMessageResourceName 错误消息资源名称；

[DataType]

指定与某个数据字段关联的附加类型的名称（一个 DataType 枚举值，如 EmailAddress、Url 或 Password）。

[DisplayName]

数据字段显示名称

[StringLength]

指定数据字段中允许的字符串最大长度。

[RegularExpression]

指定数据字段值必须与指定的正则表达式匹配。

[Range]

指定数据字段值的数值范围限制。

[PropertiesMustMatch][ValidatePasswordLength]

自定义属性

1.禁用session
假如您用不到session会话跟踪请务必禁用它。您可以在每个asp.net页面中设置如下:
<%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="WebApplication1.WebForm1"

EnableSessionState="false" %>

当然您可以在web.config应用程序配置设置中设计<sessionState>mode的值为Off.

2.输出缓冲设置
这个方法对你的应用很有帮助.
asp.net应用程序基本上在服务器端批量生成数据，这时必须设置Response.Flush清空缓冲区。这样会减轻服务器端的缓冲区压力。

<%response.buffer=true%>
替换成
<%response.flush=true%>

3.避免服务器端验证.
用客户端验证代替服务器端验证.服务器端数据验证将会大量消耗您的服务器

上的资源,并且会代来大量的页面数据回传.

4.尽量多使用Repater控件，而不要使用DataList, DataGrid, 和 DataView 控件

Asp.net是一个非常好的平台，不幸的是,有很多控件会大量生成html代码，这

样务必会造成性能上的问题.Asp.net repeater 控件非常好用。使用它你将会

额外多写一些代码,但是将来您会发现它带来的好处远比多写代码带来的麻烦。

5.在执行大动作操作时请使用 HttpResponse.IsClientConnected
if (Response.IsClientConnected)
{
// If still connected, redirect
// to another page.
Response.Redirect("Page2CS.aspx", false);
}
Response.Redirect有什么错误吗，请继续答案在下面

6.使用HTTPServerUtility.Transfer去替换Response.Redirect.
Redirect(重定向)非常麻烦,它仅用于用于从当前物理服务器跳转到其它服务

器.如果只是在本服务器内页面跳转请使用transfer(转发),这样会减少很多没

有必要的客户端请求.

7.当使用服务器端验证时请务必使用Page.IsValid检查页面是否能过验证
由于您使用了验证控件,你可能认为asp.net会为处理以下的所有事情，是这样吗？

错！当有无效数据传到服务器端时IsVlid属性被改为fasle.在继续处理您的表单之前请检查Page.IsValid属性

8.部署应用程序请使用Release版本
在部署应用程序时请确定您的应用程序应是Release版本而不是Debug版本.假如您认为这无关仅要,你就错了。

如果使用debug模板极容易发生请求超时。部署成Release版本,你将会发现速度有很大的提升.

9.关闭 Tracing(追踪)
Tracing是非常可怕的,你有没有忘记关闭它.假如没用，请确定编辑web.config并且关闭它.它将占用大量您的程序资源
<configuration>
<system.web>
<trace enabled="false" pageOutput="false" />
<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true"/>
<compilation debug="false" />
</system.web>
</configuration>

10.Page.IsPostBack要经常去使用
请确定不要执行太多回传代码，我已经记不清有多少开发者忘记使用检查IsPostBack属性.我在平常开发中会经常使用该属性检查.

11.避免使用异常
避免抛出异常和处理异常。除非在万不得已情况下使用异常处理。

异常是相当的浪费服务器端资源并会大大降低效率.尽量不使用异常处理。

12.设置缓存(Caching)
使用页面快速设置页页Caching和使用ASP.net缓冲API!

有很多东西要学,这个可不是你想像中那么简单.这个有很多策略要采用.什么时候使用缓冲?你使用缓存了吗？

13.设置每一次请求缓存
使用HTTPContect.Items仅要添加一个页面用来设置每一个请求缓存.

14.StringBuilder类的使用
StringBuilder.Append 的速要比String + String速度快的多。

假如您连接的字符串较上可以不使用，当连接次数大于3次上建议使用StringBuilder.Append方法，当然也可以使用String.Concat

15.关闭ViewState
假如你没有使用表单数据回传,那么关闭viewsate。控件回自动打开viewstate这样回减慢你应用程序速度.

public ShowOrdersTablePage()
{
this.Init += new EventHandler(Page_Init);
}

private void Page_Init(object sender, System.EventArgs e)
{
this.EnableViewState = false;
}

16.使用分页
.net应用程序分页有利用应用程序效率.每次尽量显示小部分数据，这样会加快页面显示速度。请小心使用混合缓存，请不要设置所有数据在缓存区中。

17.当更新应用程序时使用AppOffline.htm
我非常讨厌asp.net默认错误消息.我是那么的开心假如我再也看不到那些错误消息.确定您的用户也不要看到它.使用AppOffline.htm去替代它。

18.控件使用ControlState而不使用ViewState

19.使用finally方法回收资源
假如你在应用中大量使用数据库连接和访问文件,请确定在用完后关闭它们.

finally块是程序中最后被执行,因此在这里面的代码会确宝一定会被执行，关闭代码一定要在这个方法块中执行

以下示例针对 SalesOrderHeader 表和 SalesOrderDetail 表执行 GroupJoin 以查找每个客户的订单数。组联接等效于左外部联接，它返回第一个（左侧）数据源的每个元素（即使其他数据源中没有关联元素）。

 1 using (AdventureWorksEntities AWEntities = new AdventureWorksEntities())
 2 {
 3     ObjectQuery<SalesOrderHeader> orders = AWEntities.SalesOrderHeader;
 4     ObjectQuery<SalesOrderDetail> details = AWEntities.SalesOrderDetail;
 5 
 6     var query =
 7         from order in orders
 8         join detail in details
 9         on order.SalesOrderID
10         equals detail.SalesOrderID into orderGroup
11         select new
12         {
13             CustomerID = order.SalesOrderID,
14             OrderCount = orderGroup.Count()
15         };
16 
17     foreach (var order in query)
18     {
19         Console.WriteLine("CustomerID: {0}  Orders Count: {1}",
20             order.CustomerID,
21             order.OrderCount);
22     }
23 }
24 
25  

1、使用 Entity FrameWork  删除数据，着实是一件比较头疼的数据，若是少量数据，可以使用以下方法删除

 using (DB.Entity.StudentDBEntities context = new DB.Entity.StudentDBEntities())
            {
                foreach (var item in context.Students.Where(row => row.Isleft == true))
                {
                    context.DeleteObject(item);
                }
                context.SaveChanges();
            }

2、但是若是要删除的数据有个三五万，10万20万那该如何，若采用上述方法，保守估计也得10分钟吧，不信，你可以写个程序，打开SQL Server Profiler试一下，这时，若你不想另外配置连接字符串，可以借用EF的连接字符串，使用ADO.Net 完成批量删除功能

 .net Framework 3.5

public static void DeleteObject(SqlBtmsModel context, string deleteString)

{

    var bindingFlags = BindingFlags.Instance | BindingFlags.NonPublic;

    var factoryProperty = typeof(EntityConnection).GetProperty("StoreProviderFactory", bindingFlags);

    var factory = factoryProperty.GetValue(context.Connection, null) as DbProviderFactory;

    var connStr = (context.Connection as EntityConnection).StoreConnection.ConnectionString;

    using (var conn = factory.CreateConnection())

    {

        conn.ConnectionString = connStr;

        conn.Open();

        var cmd = factory.CreateCommand();

        cmd.Connection = conn;

        cmd.CommandText = deleteString;

        cmd.ExecuteNonQuery();

    }

}

Ø  .Net FrameWork 4.0

当然，若是你使用的是  .Net FrameWork 4.0,那你可以使用以下 方式。

using (DB.Entity.StudentDBEntities context = new DB.Entity.StudentDBEntities())
{

context.ExecuteStoreCommand("delete from Students where StudentId = @studentId", new SqlParameter("@studentId", 5));

context.ExecuteStoreCommand("insert into students (StudentName)values (@p1)", new SqlParameter("@p1", "test"));

 }注：3.5不支持此方式。

可能有人，想使用EntityCommand 进行批量删除，但是EntityCommand 仅支持 EntitySql ，问题就在这里了，EntitySql 目前不支持 Insert 、Delete 、Update操作，静等微软的下一步动作吧。