麦客网络

    如果你出生在1980至1988年间，你一定认识LiLei和HanMeimei。他们是1993年首次改版的初中英语教科书里的插图人物。剃平头的 LiLei，是一个正直向上的小男生；齐耳短发的HanMeimei，严肃保守，很像一个妇女主任。虽然两人在课本里总共也没说上几句话，但那个青春萌动的年代，插图版的英语书让很多人在课堂上浮想联翩。06年，已是上班族的“80后”网友们开始不断“考证”出他俩的爱情故事，最初的起源是天涯上一篇名叫《八一八中学英语课本中为虾米有一个奇怪的名字——Han Meimei》的帖子，后来又有风靡论坛的《LiLei，HanMeimei，和Jim Green缠绵悱恻的爱情故事》。除了李韩恋情大猜想之外，当年这套教科书里的所有人物，还包括那只叫Polly的鹦鹉，统统被翻出来八卦了一遍。

　　一个和尚挑水吃、两个和尚抬水吃、三个和尚没水吃。总寺的方丈大人得知情况后，就派来了一名主持和一名书记，共同负责解决这一问题。主持上任后，发现问题的关键是管理不到位，于是就招聘一些和尚成立了寺庙管理部来制定分工流程。为了更好地借鉴国外的先进经验，寺庙选派唐僧等领导干部出国学习取经；此外，他们还专门花钱请了天主教堂、基督教会的神父传授MBA。外国的神父呆了不久留下几个屁就走了，一个屁叫BPR，一个屁叫ERP。
　　书记也没闲着，他认为问题的关键在于人才没有充分利用、寺庙文化没有建设好，于是就成立了人力资源部和寺庙工会等等，并认认真真地走起了竞聘上岗和定岗定编的过场。
　　几天后成效出来了，三个和尚开始拼命地挑水了，可问题是怎么挑也不够喝。不仅如此，小和尚都忙着挑水、寺庙里没人念经了，日子一长，来烧香的客人越来越少，香火钱也变得拮据起来。为了解决收入问题，寺庙管理部、人力资源部等连续召开了几天的会，最后决定，成立专门的挑水部负责后勤和专门的烧香部负责市场前台。同时，为了更好地开展工作，寺庙提拔了十几名和尚分别担任副主持、主持助理，并在每个部门任命了部门小主持、副小主持、小主持助理。
　　老问题终于得到缓解了，可新的问题跟着又来了。前台负责念经的和尚总抱怨口渴水不够喝，后台挑水的和尚也抱怨人手不足、水的需求量太大而且没个准儿，不好伺候。为了更好地解决这一矛盾，经开会研究决定，成立一个新的部门：喝水响应部，专门负责协调前后台矛盾。
　　为了便于沟通、协调，每个部门都设立了对口的联系和尚。 协调虽然有了，但效果却不理想，仔细一研究，原来是由于水的需求量不准、水井数量不足等原因造成的。于是各部门又召开了几次会，决定加强前台念经和尚对饮用水的预测和念经和尚对挑水和尚满意度测评等，让前后台签署协议、相互打分，健全考核机制。为了便于打分考核，寺院特意购买了几个计算机系统，包括挑水统计系统、烧香统计系统、普通香客捐款分析系统、大香客捐款分析系统、挨上必死系统（简称IBS系统）、马上就死系统（简称MS系统）等，同时成立香火钱管理部、香火钱出账部、打井策略研究部、打井建设部、打井维护部等等。由于各个系统出来的数总不准确、都不一致，于是又成立了技术开发中心，负责各个系统的维护、二次开发。由于部门太多、办公场地不足，寺院专门成立了综合部来解决这一问题，最后决定把寺院整个变成办公区，香客烧香只许在山门外烧。
　　部门多、当官的多，文件和开会自然就多，为了减少文山会海，综合办牵头召开了N次关于减少开会的会，并下达了“关于减少文件的文件”。同时，为了精简机构、提高效率，寺院还成立了精简机构办公室、机构改革研究部等部门。
　　一切似乎都合情合理，但香火钱和喝水的问题还是迟迟不能解决。问题在哪呢？有的和尚提出来每月应该开一次分析会，于是经营分析部就应运而生了。分析需要很多数据和报表，可系统总是做不到，于是每个部门都指派了一些和尚手工统计、填写报表、给系统打工。
　　寺院空前地热闹起来，有的和尚在拼命挑水、有的和尚在拼命念经、有的和尚在拼命协调、有的和尚在拼命分析……忙来忙去，水还是不够喝、香火钱还是不够用。什么原因呢？这个和尚说流程不顺、那个和尚说任务分解不合理，这个和尚说部门界面不清、那个和尚说考核力度不够。只有三个人最清楚问题之关键所在，那三个人就是最早的那三个和尚。说来说去，就是他妈的闲人太多了！他们说：“整天瞎分析个屁！什么他妈的流程问题、职责问题、界面问题、考核问题，明明就是机构臃肿问题！早知今日，还不如当初咱们仨自觉自律一点算了！如今倒好，招来了这么一大帮傻B，一个个不干正经事还他妈的人五人六的，跟屎盆子一样甩都甩不掉！”
　　又过了一年，寺院黄了，和尚们也都死了。人们在水井边发现了几具尸体，是累死的；在寺院里发现了几千具尸体，是渴死的。

1、传统 WebForm 开发中存在的一些问题
    传统的ASP.NET开发中，微软的开发团队为开发者设计了一个在可视化设计器中拖放控件，编写代码响应事件的快速开发环境。然而，它所带来的负面效应是：
      由于控件封装了很多东西，开发者很难了解这背后的HTML是如何运作的；
      容易得到一个包含大量 ViewState 的页面，使得页面尺寸远远超过所需的内容，使得页面的打开速度较慢；
      不容易被测试
2、什么是 MVC?
    MVC（Model-View-Controller，模型-视图-控制器模式）是软件工程中的一种软件架构模式。它把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。
3、什么是ASP.NET MVC?
    ASP.NET MVC是微软的开发团队基于MVC开发的一个易于被测试的框架。它具有以下特性：
      没有数据回传
      没有在页面中保存视图状态
      开发者可以完全掌控页面的呈现过程
      易于单元测试
      易于测试驱动开发
      可扩展、可替换
      支持 WebForm 中的有关特性，如：用户控件、母版页、数据绑定、本地化等
      不在基于文件目录结构，而是将URL映射到控制器中
4、为什么使用 ASP.NET MVC?
    易于进行单元测试
    易于进行测试驱动开发
    避免了 WebForm 中大量的 ViewState 导致页面文件变得臃肿
5、MVC 与三层架构?  
    MVC是一种模式
    ASP.NET MVC是一个基于MVC模式的开发框架
    三层架构是一种架构
    至于区别，可以严格的从概念上区分开来。
    下图是MVC与三层架构的对应关系

6、MVC 与 Webform 如何抉择?  

7、两种技术并存
    ASP.NET MVC 框架只是给开发者提供欧诺个了开发 web 应用程序的一种选择，并不是要取代 WebForm 这两种技术各有优缺点，开发者需要根据实际情况，选择对应的技术有时候，可以在同一个项目中混合使用这两种技术
8、ASP.NET MVC与 Webform 技术的架构图

总结：
    看完本文，相信 ASP.NET WebForm 与 ASP.NET MVC 的选择相信大家应该可以做到心中有数了，我始终觉得，很多时候并不是什么技术好不好的问题，而是适合不适合不适合的问题或者能否把它用好的问题。打个比方：如果让千里马犁地，恐怕未必能达到理想的效果，最终可能还会抱怨，什么破马，一点劲都没有。

1、从 MySql 官方网站下载免安装程序。

2、解压，并将目录复制到实际运行目。如：D:\Program Files\MySQL\MySql3307。

3、复制 my-large.ini 到同目录下的 my.ini。

4、打开 my.ini 文件修改端口（必须）及其它配置（非必须）。

5、注册服务：D:\Program Files\MySQL\MySql3307\bin\mysqld.exe --install MySql53307。（其中MySql53307为服务名称）

6、打开注册表，并定位到 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MySql53307] 节点，修改 ImagePath 的值为："D:\Program Files\MySQL\MySql3307\bin\mysqld-nt" --defaults-file="D:\Program Files\MySQL\MySql3307\my.ini" MySQL53307。（此处也可以在注册服务时直接定义，但本人没试成功。）

7、启动服务：net start MySql53307。

8、使用命令行进入数据库实例：D:\Program Files\MySQL\MySql3307\bin\mysql.exe -u root。

9、修改密码：SET PASSWORD FOR root@localhost = PASSWORD('newpwd');。

10、重启服务：。

    很久之前有听闻过sqlite，大体上也了解sqlite的优势与应用场合。这些天看到不少朋友在谈论sqlite，连Google发布的离线版Gmail也都支持sqlite(当然是在HTML5的条件下)。现在，我就介绍下sqlite吧：
    首页说明一下，这个推荐嵌入式数据库叫sqlite，不叫sqllite,有很多网站都误报了。
    sqlite第一个ALPHA版本是生于2000年5月。经过9个年头的发展，现在最新版本是3.6.11了。
    sqlite是一个比ACCESS更小的嵌入式数据库，通常用在小型嵌入式设备上。
    官方网站：http://www.sqlite.org/
SQLite不同于其他大部分的SQL数据库引擎,因为它的首要设计目标就是简单化:
    易于管理
    易于使用
    易于嵌入其他大型程序
    易于维护和配置
    许多人喜欢SQLite因为它的小巧和快速. 但是这些特性只是它的部分优点, 使用者还会发现SQLite是非常稳定的. 出色的稳定性源于它的简单, 越简单就越不容易出错. 除了上述的简单、小巧和稳定性外, 最重要的在于SQLite力争做到简单化。
    简单化在一个数据库引擎中可以说是一个优点, 但也可能是个缺点, 主要决定于你想要做什么. 为了达到简单化, SQLite省略了一些人们认为比较有用的特性, 例如高并发性、 严格的存取控制、 丰富的内置功能、 存储过程、复杂的SQL语言特性、 XML以及Java的扩展, 超大的万亿级别的数据测量等等. 如果你需要使用上述的这些特性并且不介意它们的复杂性, 那么SQLite也许就不适合你了. SQLite没有打算作为一个企业级的数据库引擎, 也并不打算和Oracle或者PostgreSQL竞争。
    仅凭经验来说SQLite适用于以下场合: 当你更看中简单的管理、使用和维护数据库, 而不是那些企业级数据库提供的不计其数的复杂功能的时候，使用SQLite是一个比较明智的选择. 事实也证明, 人们在许多情况下已经清楚的认识到简单就是最好的选择。
SQLite最佳试用场合
    网站
    作为数据库引擎SQLite适用于中小规模流量的网站(也就是说, 99.9%的网站). SQLite可以处理多少网站流量在于网站的数据库有多大的压力. 通常来说, 如果一个网站的点击率少于100000次/天的话, SQLite是可以正常运行的. 100000次/天是一个保守的估计, 不是一个准确的上限. 事实证明, 即使是10倍的上述流量的情况下SQLite依然可以正常运行。
    嵌入式设备和应用软件
    因为SQLite数据库几乎不需要管理, 因此对于那些无人值守运行或无人工技术支持的设备或服务, SQLite是一个很好的选择. SQLite能很好的适用于手机, PDA, 机顶盒, 以及其他仪器. 作为一个嵌入式数据库它也能够很好的应用于客户端程序。
    应用程序文件格式
    SQLite 作为桌面应用程序的本地磁盘文件格式取得了巨大成功.例如金融分析工具、CAD 包、档案管理程序等等. 一般的数据库打开操作需要调用sqlite3_open()函数，并且标记一个显式本地事务的起始点（BEGIN TRANSACTION）来保证以独占的方式得到文件的内容. 文件保存将执行一个提交（COMMIT）同时标记另一个显式本地事务起始点. 这种事务处理的作用就是保证对于应用程序数据文件的更新是原子的、持久的、独立的和一致的.数据库里可以加入一些临时的触发器,用来把所有的改变记录在一张临时的取消/重做日志表中. 当用户按下取消/重做按钮的时候这些改变将可以被回滚. 应用这项技术实现一个无限级的取消/重做功能只需要编写很少的代码。
    替代某些特别的文件格式
    许多程序使用fopen(), fread(), 或 fwrite()函数创建和管理一些自定义的文件用来保存数据. 使用SQLite替代这些自定义的文件格式将是一种很好的选择。
    内部的或临时的数据库
    对于那些有大量的数据需要用不同的方式筛选分类的程序, 相对于编写同样功能的代码, 如果你把数据读入一个内存中的SQLite数据库, 然后使用连接查询和ORDER BY子句按一定的顺序和排列提取需要的数据, 通常会更简单和快速. 按照上述的方法使用内嵌的SQLite数据库将会使程序更富有灵活性, 因为添加新的列或索引不用重写任何查询语句。
    命令行数据集分析工具
    有经验的SQL用户可以使用SQLite命令行程序去分析各种混杂的数据集. 原是数据可以从CSV（逗号分隔值文件）文件中导入, 然后被切分产生无数的综合数据报告. 可能得用法包括网站日志分析, 运动统计分析, 编辑规划标准, 分析试验结果.当然你也可以用企业级的客户端/服务器数据库来做同样的事情. 在这种情况下使用SQLite的好处是: SQLite的部署更为简单并且结果数据库是一个单独的文件, 你可以把它存储在软盘或者优盘或者直接通过email发给同事。
    在Demo或测试版的时候作为企业级数据库的替代品
    如果你正在编写一个使用企业级数据库引擎的客户端程序, 使用一个允许你连接不同SQL数据库引擎的通用型数据库后台将是很有意义的. 其更大的意义在于将SQLite数据库引擎静态的连接到客户端程序当中，从而内嵌SQLite作为混合的数据库支持. 这样客户端程序就可以使用SQLite数据库文件做独立的测试或者验证。
    数据库教学
    因为SQLite的安装和使用非常的简单(安装过程几乎忽略不计, 只需要拷贝SQLite源代码或sqlite.exe可执行文件到目标主机, 然后直接运行就可以) 所以它非常适合用来讲解SQL语句. 同学们可以非常简单的创建他们喜欢的数据库, 然后通过电子邮件发给老师批注或打分. 对于那些感兴趣怎样实现一个关系型数据库管理系统（RDBMS）的高层次的学生, 按照模块化设计且拥有很好的注释和文档的SQLite源代码, 将为他们打下良好的基础. 这并不是说SQLite就是如何实现其他数据库引擎的精确模型, 但是很适合学生们了解SQLite是如何快速工作的, 从而掌握其他数据库系统的设计实现原则。
    试验SQL语言的扩展
    SQLite简单且模块化的设计使得它可以成为一个用来测试数据库语言特性或新想法的优秀的原型平台。

    用PHP调用mysql，内置的LAST_INSERT_ID()这个函数可能没有什么人用，用的最多的还是mysql_insert_id();其实，这两个是有区别的，LAST_INSERT_ID()能返回 bigint 值的 ID。而，mysql_insert_id 返回的是 int。如果你的 id 是 unsigned int，或者 bigint 的。那么，可能是返回的是错误的。而要用 LAST_INSERT_ID()代替。
    还有些朋友，返回的都是 0，不知道怎么回事，其实 LAST_INSERT_ID()返回的是 AUTO_INCREMENT 的 ID。如果表结构中没有设置 AUTO_INCREMENT 那么也无法返回。
    还有些人，还是返回为 0。那么你就要检查一下，是不是用了 insert delay 的功能。这种情况下是不会返回即时的返回 ID 值的。
    很多人喜欢用 select max(id) ... 来替换这个 last_insert_id, 实际上，select max(id)是非线程安全的，很有可能，其他线程插入了新的数据，你就查不到你上次插入的 ID 了。而 last_insert_id 是和一个mysql connect相对应的，也就是和你的当前线程相对应的，不会受其他线程的干扰。如果你的数据库发生了一些奇怪的错误，比如，本来是要更新 A 数据的信息的，结果 B 数据被更新了，而且是有时候正确，有时候不正确，人多的时候会非常的不正确。就要看看是不是 用了 select max(id)。

　　不论什么样的团队总会面临有人要离开的情况，不论离开的那位是菜鸟还是高手。离开的原因很多，当然大部分可能还是因为待遇（虽然$不是万能的，但是没$就万万不能，这句话的确是真理啊）。
　　最早开始思考关于“离开”这个问题的时候，是听同事抱怨。说他带的人老是和他提要加工资，然后几个已经离开的人现在打电话都不接。之前，我也和领导提出过离开，但因为种种原因，最终我还是留了下来。后来我旧事重提，得到的评价是我这人不够专一，也终于弄清楚了，为啥领导总爱说我“私心很重”.
　　也许看起来会让人觉得是在推卸责任，但我还是觉得在“离开”这个问题上，首先应该自我检讨的应该是“被离开”的那一方。团队认为个人不适合，没法为团队做出贡献，自然会选择放弃。个人觉得团队不适合自己发展，无法满足自己的期望，也同样会选择放弃。选择放弃自己的理想，勉强留下的，能有什么作为？
　　有些领导喜欢通过加强物质文明建设，并以此作为留住精英的筹码。但本人认为，如果只能用钱留住的人，最好还是让他走吧。就算是精英，没法实践自己的理念，没法实现自己的理想，只能通过$来满足自己。久而久之也会产生惰性，不再记得曾经为了追逐理想而激情四溢的日子。这不论对于个人，还是对于团队，都是一个巨大的损失。
　　往往我们作为一个团队的负责人时，一旦有人提出“离开”,特别是自己比较器重的。总会大发雷霆，有种被人背叛的感觉。但我们是否设身处地想过，为什么自己如此器重的人会提出离开？是待遇问题吗？我们能否给出另他满意的待遇？如果不能，我们能否从其他方面了解一下他需要什么，给他更大的发展空间或是在一定程度上帮助他实现他的目标、体现他的价值？当然，还有一种更省事，但不是很有效的方法“忽悠”,用尽嘴皮子，拼命灌输，扯我们有多伟大的理想，将来能怎么样怎么样。不过，就一般情况来说，如果待遇没有办法解决的问题，忽悠也只是一个缓兵之计，要离开的还是会离开的。
　　回到正题，“离开”并不是一个一定要强调谁对谁错的问题。所谓人往高处走，水往低处流。有人想要离开，说明他发现了一个更适合他的地方，作为曾经的伙伴，我们难道不应该祝福他吗？另外，从伙伴的离去，在抱怨之前，是否更应该好好反思一下自己？究竟是什么原因导致了目前的局面，是否还有挽回的余地。
　　留住一个人才的方法其实很多，$是一方面，但并不是每个人都只在乎眼前的蝇头小利。利用自己的个人魅力，感染对方，提供一个广阔的发展空间也是一个不错的方法。就好像那些优秀的推销员一样，发现别人的需求，再针对不同的对象进行引导，在一个个平淡却深刻的细节中，慢慢将对方带入自己的轨道。只是一味的宣传，我们的公司如何优秀，我们的产品如何实用，并不见得就能打动对方，甚至还会带来反效果（看街上那些不开窍的推销员就知道了）。对每一个人因材施教、因势利导，让每一个人都满怀激情，并发挥出最大的作用，相信得到的$（当然包括很多其他方面的回报），一定能够满足每个团队成员的期望。
　　天下无不散之筵席，再好的朋友都有离别的一天。合作伙伴为了理想走上新的道路，不代表就会成为敌人。用另一个方式进行合作，互相促进、互相扶持才是该做的事情。“离开”不是问题，关键是要从“离开”中找原因，并且能保证所有团队成员在一起时能融为一体，即使离开了也能相互扶持。

1. 调整IIS 7应用程序池队列长度
　　由原来的默认1000改为65535.
　　IIS Manager > ApplicationPools > Advanced Settings
　　Queue Length : 65535
2.  调整IIS 7的appConcurrentRequestLimit设置
　　由原来的默认5000改为100000.
　　appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000
　　在%systemroot%\System32\inetsrv\config\applicationHost.config中可以查看到该设置。
3. 调整machine.config中的processModel>requestQueueLimit的设置
　　由原来的默认5000改为100000.
　　<configuration>
　　<system.web>
　　<processModel requestQueueLimit=“100000”/>
4. 修改注册表，调整IIS 7支持的同时TCPIP连接数
　　由原来的默认5000改为100000.
　　reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameters /v MaxConnections /t REG_DWORD /d 1000000

1、Assembly.Load()
　　这个方法通过程序集的长名称(包括程序集名，版本信息，语言文化，公钥标记)来加载程序集的，会加载此程序集引用的其他程序集，一般情况下都应该优先使用 这个方法，他的执行效率比LoadFrom要高很多，而且不会造成重复加载的问题(原因在第2点上说明)
　　使用这个方法的时候， CLR会应用一定的策略来查找程序集，实际上CLR按如下的顺序来定位程序集：
　　⑴如果程序集有强名称，在首先在全局程序集缓(GAC)中查找程序集。
　　⑵如果程序集的强名称没有正确指定或GAC中找不到，那么通过配置文件中的<codebase>元素指定的URL来查找
　　⑶如果没有指定强名称或是在GAC中找不到，CLR会探测特定的文件夹：
　　假设你的应用程序目录是C:\AppDir,<probing>元素中的privatePath指定了一个路径Path1,你要定位的程序集是AssemblyName.dll则CLR将按照如下顺序定位程序集
　　C:\AppDir\AssemblyName.dll
　　C:\AppDir\AssemblyName\AssemblyName.dll
　　C:\AppDir\Path1\AssemblyName.dll
　　C:\AppDir\Path1\AssemblyName\AssemblyName.dll
　　如果以上方法不能找到程序集，会发生编译错误，如果是动态加载程序集，会在运行时抛出异常！
2、Assembly.LoadFrom()
　　这个方法从指定的路径来加载程序集，实际上这个方法被调用的时候，CLR会打开这个文件，获取其中的程序集版本，语言文化，公钥标记等信息，把他们传递给 Load方法，接着，Load方法采用上面的策略来查找程序集。如果找到了程序集，会和LoadFrom方法中指定的路径做比较，如果路径相同，该程序集 会被认为是应用程序的一部分，如果路径不同或Load方法没有找到程序集，那该程序集只是被作为一个“数据文件”来加载，不会被认为是应用程序的一部分。 这就是在第1点中提到的Load方法比LoadFrom方法的执行效率高的原因。另外，由于可能把程序集作为“数据文件”来加载，所以使用 LoadFrom从不同路径加载相同程序集的时候会导致重复加载。当然这个方法会加载此程序集引用的其他程序集。
3、Assembly.LoadFile()
　　这个方法是从指定的文件来加载程序集，和上面方法的不同之处是这个方法不会加载此程序集引用的其他程序集！
　　结论：一般大家应该优先选择Load方法来加载程序集，如果遇到需要使用LoadFrom方法的时候，最好改变设计而用Load方法来代替！

1. 什么是局部类型？
　　C# 2.0 引入了局部类型的概念。局部类型允许我们将一个类、结构或接口分成几个部分，分别实现在几个不同的。cs文件中。
　　局部类型适用于以下情况：
　　(1) 类型特别大，不宜放在一个文件中实现。
　　(2) 一个类型中的一部分代码为自动化工具生成的代码，不宜与我们自己编写的代码混合在一起。
　　(3) 需要多人合作编写一个类。
　　局部类型是一个纯语言层的编译处理，不影响任何执行机制--事实上C#编译器在编译的时候仍会将各个部分的局部类型合并成一个完整的类。
　　public partial class Program
　　{
　　    static void Main(string[] args)
　　    {
　　    }
　　}
　　partial class Program
　　{
　　    public void Test()
　　    {
　　    }
　　}
2. 局部类型的限制
　　(1) 局部类型只适用于类、接口、结构，不支持委托和枚举。
　　(2) 同一个类型的各个部分必须都有修饰符 partial.
　　(3) 使用局部类型时，一个类型的各个部分必须位于相同的命名空间中。
　　(4) 一个类型的各个部分必须被同时编译。
3. 局部类型的注意点
　　(1) 关键字partial是一个上下文关键字，只有和 class、struct、interface 放在一起时才有关键字的含义。因此partial的引入不会影响现有代码中名称为partial的变量。
　　(2) 局部类型的各个部分一般是分开放在几个不同的。cs文件中，但C#编译器允许我们将他们放在同一文件中。
4. 局部类型的应用特性
　　在局部类型上的特性具有“累加”效应。
　　[Attribute1, Attribute2(“Hello”)]
　　partial class Class1{}
　　[Attribute3, Attribute2(“Exit”)]
　　partial class Class1{}
　　相当于
　　[Attribute1, Attribute2(“Hello”)， Attribute3, Attribute2(“Exit”)]
　　class Class1 {}
　　注：Attribute2属性允许在类上多次使用。
5. 局部类型上的修饰符
　　(1) 一个类型的各个部分上的访问修饰符必须维持一致性。
　　(2) 如果一个类型有一个部分使用了abstract修饰符，那么整个类都将被视为抽象类。
　　(3) 如果一个类型有一个部分使用了 sealed 修饰符，那么整个类都将被视为密封类。
　　(4) 一个类的各个部分不能使用相互矛盾的修饰符，比如不能在一个部分上使用abstract,又在另一个部分上使用sealed.
6. 局部类型的基类和接口
　　(1) 一个类型的各个部分上指定的基类必须一致。某个部分可以不指定基类，但如果指定，则必须相同。
　　(2) 局部类型上的接口具有“累加”效应。
　　partial class Class2: Iinterface1, Iinterface2 {}
　　partial class Class2: Iinterface3 {}
　　partial class Class2: Iinterface2 {}
　　相当于
　　class Class2: Iinterface1, Iinterface2, Iinterface3 {}