飞鹰的专栏

visual studio 2010 已经出来很久了，很多大牛们都已经投入其中开始研究了。我在网上看到一张.net 4.0的海报，很漂亮，很全地概括了4.0的知识点，贴在这里，供大家参考。

不知你是否意识到，围绕着什么才是实现异构的应用到应用通信的“正确”方式，一场争论正进行的如火如荼：虽然当前主流的方式明显地集中在基于SOAP、WSDL和WS-*规范的Web Services领域，但也有少数人用细小但洪亮的声音主张说更好的方式是REST，表述性状态转移（REpresentational State Transfer）的简称。在本文中，我不会涉及争论的话题，而是尝试对REST和RES

“架构的视角每个人都不一样，这位在eBay、携程、唯品会等平台型互联网公司都工作过的老司机就以平台架构视角和大家分享架构心得体会。一家之言，欢迎讨论。本文首发于InfoQ垂直公众号「聊聊架构」，ID：archtime。我对架构定义的理解大概在7~8年前，我曾经有一个美国对口的架构师导师，他对我讲架构其实是发现利益相关者（stakeholder），然后解决他们的关注点（con

目的：实现一个2008serve的IIS的虚拟目录（通过网络路径（UNC）的形式，共享在另外一个2008服务器上）准备工作1.共享资源服务器为 ShareServer，IP地址为：192.168.100.10；2.Web服务器为 WebServer，IP地址为：192.168.100.20详细步骤：一、共享账户的建立1.在WebServer上建立一个

构建在Windows平台之上的网站，往往会被业内众多架构师认为很“保守”。很大部分原因，是由于微软技术体系的封闭和部分技术人员的短视造成的。由于长期缺乏开源支持，所以只能“闭门造车”，这样很容易形成思维局限性和短板。就拿图片服务器为例子，如果前期没有容量规划和可扩展的设计，那么随着图片文件的不断增多和访问量的上升，由于在性能、容错/容灾、扩展性等方面的设计不足，后续将会给开发、运维工作带来很多问题

如何部署软件 - 让你团队的部署像地狱一样无聊且毫无压力作者 Zach Holman本文为 Coding 用户协作翻译，转载请注明来源。如果你对本文的翻译有建议，欢迎提交 Pull Request 。让我们来聊聊部署无论你何时对自己的代码库做出改动，总会伴随着要破坏一些东西的风险。没有人喜欢宕机, 没有人喜欢暴躁的用户, 也没有人喜欢生气的经理，所以部署新代码到生产

最近在重构过去写过的一些程序，发现过去写的代码虽然具有面向对象的一面，但设计不够好，没有体现出领域模型设计的味道。有一下三点原则没有做好：1.类的设计不够精准，不能精确的表达出该类所代表的领域模型概念。2.类与类之间的交互也没有体现出模型的交互，而是充斥着隐形的类与类之间的直接调用（暂不谈可扩展原则而去强调调用接口，而不是具体类）。3.类的设计过于粗粒度，不够细化。原则1是大家最不

.NET框架中的缓存原文地址http://msdn.microsoft.com/en-us/library/dd997357.aspx 缓存使得你可以快速的获取内存中存储的数据。当再次访问数据的时候，应用从缓存中获取数据，而不是从数据的原始源获取。这么做可以提高性能和扩展性。另外，当数据源临时不可用的时候，缓存使得数据还是可用的。 你可以用.NET提供的缓存功能提高

一个封装比较完整的FTP类——clsFTP前几天，看见园子里面的博友写了一个支持断点续传的FTP类，一时技痒，干脆写了个更完整的clsFtp类。只是我写这个clsFtp不是支持断点续传的目的，而是为了封装FTP几个基本常用的操作接口。功能ü         建立FTP链接ü         支持代理ü         多种重载的同步上传文件ü         多

Serialization的概念      Serialization是.NET中一种实现对象持久性（Persistent）的机制。它是一个将对象中的数据转换成一个单一元素（通常是Stream）的过程。它的逆过程是Deserialization。Serialization的核心概念是将一个对象的所有数据看作一个独立的单元。      一般说来，在两种情况下非常需要Serializa

这些年，通过不断的努力，逐渐的在成长。曾经开发过MES系统，SPC系统，HR系统，ERP系统的二次开发，当然这些系统都是针对公司内部流程的信息化。渐渐的，将把这些系统打通，去掌握公司的全局信息技术架构。而自己一直处于开发管理者的位置，自我认知，还需要很多的知识去补充，去学习。贴下这张图，作为未来努力的一个方向。已自励。

您是否对于分层架构有些迷惑，或者对现有的分层架构模式想再提高一些，看看下面这些或牛人，或码农的分层架构图，希望对大家，对自己有所帮助，已拨开分层架构这片迷雾。说明：以下图片引用自传说中的弦哥中的一篇文章。1.01，User Interface即UI层：该层作为数据输入和展示的界面，是与用户交互的有效途径，所以它起着至关重要的作用。往往给人第一印象的就是UI层，在设计

.NET平台上的分层架构（很多朋友称其为“三层架构”），似乎是一个长盛不衰的话题。经常看到许多朋友对其进行分析、探讨、辩论甚至是抨击。笔者在仔细阅读了大量这方面文章后，认为许多朋友在分层架构的理解上存在两个比较大的偏颇：1.没有从本质角度去理解分层的内涵，而只是了解其表象。2.对分层架构的理解过于狭隘，只是少数概念，而又不够深入。许多朋友言“分层”则必称“DAL

引用：http://tech.it168.com/a2011/0512/1189/000001189668_all.shtml在我们刚开始学习架构的时候，首先会想到分层的概念，分层架构比较经典的是三层架构，那么，什么是三层架构呢?它包括表现层，业务层，数据访问层;而对于一个新手来说，从抽象意义上的三层架构，逻辑上就划分为三个层。　　　　这个是最基本的三层架构模式

如果要自己创建缓存框架，有两个缓存容器可以选取：Hashtable,Dictionary.两者都是已键与值的方式来存储对象。但是两者究竟有什么区别，谁胜谁优，看了下面这篇文章，也许你会收获一些。哈希表，名-值对。类似于字典(比数组更强大)。哈希表是经过优化的，访问下标的对象先散列过。如果以任意类型键值访问其中元素会快于其他集合。GetHashCode()方法返回一个int型数据

1、关联双向关联：C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。

在开发中，经常会遇到这种情况，在A.dll中需要反射B.dll中的类型，如果稍不注意，就会产生运行时错误。关于跨程序集的反射，记住两点就可以：（1）如果使用typeof，编译能通过，则跨程序集的反射一定可以正常运行。可以说，typeof是支持强类型的。比如Type supType = typeof(EnterpriseServerBase.DataAccess.IDBAccesser)

不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。事务的具体定义事务提供一种机制将一个活动涉及的...