一般我们说拿出解决方案，首先应确认要解决的问题是什么，没有明确的目标容易在寻找解决方案的过程中迷失方向。
3.1我们开发的软件是什么样的软件？
软件即以特定计算机语言编写，为解决特定问题而开发的计算机工具，软件分为系统软件（操作系统、数据库系统）与应用软件（某某财务软件、某某信息系统），在此我们讨论的软件系统基本为上为解决企业信息化而建立的应用软件；应用软件由于是运行于特定环境的，因此也受这些特定因素影响，一般情况下，为Windows开发的软件，很难在类Linux、或MacOS上运行，反之亦然（有些读者可能要反驳到：好多用C++开发的软件，就可以同时在很多平台上运行，JAVA的应用就可以跨平台，这些并非是本人孤陋寡闻），“很难”并非不可能，只是为了实现这样的目的有这个必要嘛？实现的代价是什么？有没有更轻松的解决方案？
在国内像我们这样开发“信息管理系统”的公司占了主要比例（具体多少公司，没有统计过，只是我认识的公司都是开发这样的系统的），在此我们可以定位“软件”即为：信息管理系统软件，是企业为解决信息化管理、落实管理方式而建立的管理手段与工具。
“信息管理系统”依据用户的数量、处理的数据量可以粗略分类为小型桌面软件（单机单用户）、中型网络应用软件（局域网多用户，比如：企业进销存软件）与大型分布式软件（局域网或Internet网内，用户数量大），像“记事本”之类的软件我是不愿意开发的，不开发的原因不是因为没有技术含量，而是这样的应用很难得到用户对它应用价值的认可，因此得不到应有的回报也就不奇怪了。用户委托我们开发或向我们购买的都是哪些具有一定用户数量，大家协同解决企业管理问题的哪些软件。
本架构由于是基于.Net开发的应用框架，当然读者群体也是.Net领域的Coder，但无论是哪个技术体系的支持者、使用者都无所谓，在实际应用中遇到的问题都是一样的，最后得出的结论是：殊途同归，无论使用什么工具、技术，解决问题的思想都是一样的。因此，我们观察好多应用最广泛的应用服务器，它们的工作原理都是一样的。
3.2用户的组织结构是什么，以及组织结构对软件结构的影响
使用信息化管理软件的团体或组织都不是一个人在使用，一般都有很多岗位协调完成某一事务（即我们常说的业务流程或业务逻辑），因为过于简单的事务没有必要使用计算机来完成，一个人在工作能力范围内能完成的事务不可能成为软件开发的需求，只有在个人或团体靠单纯的体力劳动感觉乏味或力不从心才会想办法找替代工具，才能形成需求，促成软件开发或软件采购。
任何团体、组织都有其管理模式，管理模式定义了企业的组织结构，在此我们把企业的组织机构作一些粗略的分类与探讨。
微型企业：个体户或企业人数较少，业务也较少，发生的业务单一，企业管理的内容限于记录销售额，点清现金，工作量个人完全可以胜任，工作人员要么是自己，要么是自己的家庭成员，岗位职责界限模糊，即使销售或现金记录有误也不必过多解释，都是自己或自家的钱，没有必要将简单的事情复杂化。这样的企业没有信息化的需求，连企业主自身也没有完全认识到信息化的价值，只感觉信息化很好，要在自己的企业内实现完全是很遥远的事。
小型企业：只有一个单独的团体或组织，人数不多（50人以下），在同一办公地点办公，信息化管理软件完成的功能是业务办理与流程监控、记录、归档与初步的分析，指导决策人决策，这样的组织一般以企业老总为中心带头实现，各部门经理为业务主办与负责，部门工作人员负责完成具体事务，这样的企业特点是老总较强势，没有老总的带头与推动，信息化的实现基本上是不可能的，但另一方面由于老总的强势，信息化的业务流程中总是体现出老总的个人意志，业务流程的建立不一定是最科学的，取决于老总的认识与实施人员与老总的沟通。这样的信息化实施由于首先得到了老总的认可与推动，在实施时也比较顺利。
中型企业：企业具备了一定的规模，在某地设有总公司办公点，下设区域级分支机构，也可能按业务化分为分支机构或分公司，但各个机构的人员配置与功能与上述小型企业的人数与功能完成一致，只是分支机构必须接受总部的监督与指挥，在总部的规则指导下，分支机构有自主权，单独核算，总部的管理指标不但有自己的指标，同时也是所有分支机构的管理指标的总和，决策管理层需要掌握分支机构的经营情况，也需掌握总体发展情况；另外，各分支机构有可能在同一办公地点分开办公，也有可能在不同的城市办公，地域分布有跨度。企业管理层熟悉企业管理与业务流程，对信息化管理有相当的认识，同时也抱有期望，希望建立一套为企业管理服务的核心系统，降低管理成本，提升生产力，与同行保持竞争力平等（可能同行都具备了管理信息化能力，此时企业信息化只是企业的必备能力，而不是差异化竞争力）。
大型企业：企业具备相当规模，设立分支机构，地理分布跨度大，人员众多，业务多样，各分支机构俱有中型企业的管理需求，同时总公司可能以行业的角度进行分析与决策，对数据挖掘与分析有较高需求。管理层对信息化的认识跨度较大，人员众多，有些人对信息化认识深刻，有些则停留在感性认识，认为可有可无，企业信息化管理维护部门有信息化管理的专业人员，这些专业人员有信息技术维护的能力，但对企业业务管理则缺乏认识。信息化的成败依赖信息化实施人员与甲方的协调和管理层的推动力。因此，在大型企业实施信息化的难度高，失败案例比比皆是，究其原因主要是领导层重视信息化，但不是信息化的使用者，信息化维护与实施人员不懂业务，业务基层人员没有信息化认识，没有全局观，协调配合意识差，只注重本岗位工作。
微型企业
小型企业
中型企业
大型企业
人数与组成
10人以下
50人以下
500人以下
500人以上
人员组成
自己或家庭成员
自己
家庭成员
朋友
雇员
股东
董事会
管理层对信息化的认识
无或限于感性
感性或初识其价值
初识其价值，也可能认识深刻
管理层对信息化的推动欲望
无
相当强
强
一般
信息化对企业生产力的提升
无或可能是多余成本
明显提升
局部有提升，总体提升要看IT规划是否科学
实施难度
低
难
较难
非常难
实施周期
短
长
很长
多系统整合
较少
复杂
3.3用户对软件系统的性能要求如何，如何在需要的时候提升性能
n软件开发本身有缺陷，很多软件开发人员对性能都没有概念，什么样的代码会对性能造成什么影响，都是按自己的感觉，只有软件部署后才发现10个用户同时访问都发生响应超时，这样的软件开发在设计时就存在缺限。
n软件开发首先是按用户的当前用户数设计的，没有考虑将来的发展，当规模增大时对软件、硬件的运行性能提出新要求，如果单纯靠提升硬件性能无法解决的问题，只能靠优化软件性能来解决。当然优化软件性能有成本与代价的问题，设计良好的软件框架，在扩展应用服务器的数量时是透明的，能够有效的利用不同硬件配置的服务器，有些应用的设计本身就不支持这样的扩展，要提高运行性能只能更换性能更好的服务器。
顺便解释一下，性能优化包含两个方面，硬件优化与软件优化，硬件速度的优化受技术条件的限制，成几百倍上万倍的性能提升很困难，有时是不可能的，但通过软件算法优化将性能提升上万倍却很普通，即相同的硬件配置，使用不同的算法，表现出的性能则不同。
我们举个例子，如果用户希望将现有应用的性能提升100倍，硬件提升的办法可能是：购买一台性能是当前硬件服务器100倍的服务器（应用不支持集群与负载均衡），或者增加购买99台与当前性能相当的服务器（应用支持集群与负载均衡），第一种方案在很多情况下是不可行的，原因为可能这样的服务器不存在，也可能成本太高而无力购买，购买一台普通4路服务器与购买一台小型机的成本并不是按性能的提升倍数来核算的；第二种可选方案比较可行，因为购买相同配置的服务器是用户能接受的成本增加。
如果上述提升当前应用100倍的性能通过软件优化能解决，则节省了购买硬件服务器的开支，相当经济，成为用户与软件开发人员的首选。
有些软件性能提升到极致后，还要结合增加服务器数量的方式来进行负载均衡，用多台服务器来增加应用性能，因此也是当前在软件优化不可行时的普遍做法。
性能优化是一个复杂的问题，需要结合实际的硬件条件、软件架构具体问题具体分析，我们在此讨论的只是一些原则，通过软件优化提升性能一方面是可行性高，另外成本投资小，应优先考虑。
避免软件性能的方法：
与用户接触时把性能问题的表象与可能产生的成本与用户做深入的交流，在用户并不需要高性能时努力提高负载能力可能并不值得，而在用户需要高负载能力与可配置能力时软件框架却不支持，需要重新设计整个软件时更是得不偿失。
需求调研时按最大负载估算，提前规划。
应用设计良好的架构，在需要时能够动态调整满足要求（能做到这一步当然是一切OK了）。
优化应用的运行时性能：数据库优化、网络传输优化、算法优化、硬件性能增强。
3.4软件发开人员本身对软件开发的影响，如何克服这些影响
应用软件开发之所以困难在于整个软件开发过程不是简单的代码堆砌，而是人与人的沟通交流。我们曾经做过一个测试，参加测试的一共有10人，让其中9人在房间外等候，实验者对第一人叙述了一句话，让这位测试者按原意告诉下一位测试者，第二位测试者把自己听到的告诉第三位，以此类推。最终结果让观众啼笑皆非，每位测试者都把所听到的话按照自己的理解添加了个性化的修饰叙述给下一位测试者，结果传话到最后一位测试者时，已经与原来的意思完全背离了。这个实验只是再一次证明了沟通与转述的困难，而我们的应用软件开发首先是需求分析人员与用户沟通，将沟通的结果整理成文字描述，交给软件设计师，软件设计师设计出开发用例，测试人员与程序员根据开发用例进行实际的功能开发与测试，其中已经经过4次转述，其中的偏差可以想象。因此，开发一个用户最终认可的应用软件系统，要经过无数次沟通与误差纠正，任何环节出现的偏差都直接导致结果相去甚远。
软件开发人员是软件产品的生产者，其个人能力与思维方式不可避免的对软件产品形成影响，现代化的软件开发尽量消除这种个性化的影响，努力提升软件生产的成品率与流水作业的自动化水平，软件开发是个将思维过程转化为可重现的工作流程，软件开发管理水平的高低取决于这种可再现流水作业的自动化水平。基于这样的管理诉求，开发团队规定自己的编码规范，界面规范，统一需求的表达方式（文字与图示：UML），到开发企业自己的基础性软件设施等，都是在尽量消除个人的主观性影响。
因此，消除软件开发人员对软件产品的个性影响的措施可能为：
制定编码规范——统一代码的编写习惯与命名习惯（在参考文档中提供范本）。
统一需求表达方式（UML）——学习并应用UML，用文字与图表来表达需求与设计，让所有开发人员有统一认识，特别要理解团队的习惯性概念与假定。
制定界面规范——统一界面表现的字体，排列习惯，操作习惯等（在参考文档中提供范本）。
软件常用工具积累（Utility）——归类整理常用软件工具程序，提升开发速度与质量。
开发并应用通用软件基础设施——发展应用框架通用基础设施，不断复用前人的开发成果，降低应用难度，降低维护成本。
提供开发示例——新人入职时使用开发示例培训，统一开发习惯与思维模式。
3.5为解决以上问题我们的构架应具备的能力与配置
3.5.1通信能力的可配置
应用服务器的应用可以通过各种现有的通信协议传输对象与对象调用，而不用修改现有对象或代码结构，目前在.Net环境下首选当然是WCF通信基础，可通过配置应用不同的通信协议与绑定。经常见到好多同行为不同的服务定义不同的接口，每个接口有一个或多个不同的服务实现，服务端通过配置来创建合适的服务对象（IoC创建服务对象或使用对象工厂方法来创建服务对象），客户端代理调用代理方法后将调用传输到服务调用，将最终结果返回给客户端。
图中所指网络指广义的通信网络：进程内通信、进程间通信。
3.5.2应用宿主程序的适应
应用宿主程序可能是命令行程序，可能是Windows应用程序，也可能是Windows系统服务程序，也可能驻留在Web服务器内（如：IIS应用服务器）。因此，关于服务的配置应是统一的，不应有差别。
3.5.31-N层应用的可配置（纵向）
常见应用都是分层次的，根据分层形成清晰的定义，每一层各自扮演各自应有的功能与角色，使架构变得更加清晰和可维护。常见逻辑分层模型如下：
逻辑的分层并不会对逻辑架构与物理的分离造成伤害。
可能的应用场景：
1.五个逻辑层运行在同一台电脑上
2.使用独立数据库服务器的五个逻辑层
3.使用独立应用服务器和数据库服务器
4.最优化性能的WEB客户端
5.部署在负载平衡的Web集群上的五个逻辑层
6.部署在安全Web设置中的五个逻辑层
关于物理层与逻辑分层组合与部署的优缺点可以参考《ExpectC#2005BusinessObjects》中文版一书中第一章1.1.2，总得来说，架构中的物理层数是一种在性能、可扩展性、安全性和容错能力之间平衡的结果。而且，对于一个Web应用程序和一个使用桌面应用的内部网应用程序的最优化设置是不一样的。如果应用程序框架有多方面的要求，哪么它就在物理架构中需要灵活性，来有效地支持Web和桌面应用，并且同时提供最优化的性能和可扩展性。除此之外，它还需要能在面向服务的环境中创建客户端和服务器端应用程序，通过消息通信来实现互操作。
3.5.4应用层负载能力的可配置（横向）
3.5.5应用服务的动态调度
实际应用中即有与用户交互操作的应用，也存在一些定时定期执行的批量任务，这种类型的任务不需要用户的交互操作，任务按照应用的设置参数周期性的执行，在此我们称之为“自动任务”，应用服务器应具备调度“自动任务”的能力。
3.5.6应用基础设施
一个可以应用于生产的框架不但需要具备上述能力，还应满足企业级应用所必需的基础组件才能够让开发应用人员用得得心应手、顺畅，在提高生产效率的同时提高生产率、成品率。这些基础设施可以归类总结为：
l常用软件辅助（Helper）类的积累,比如：如何取本机MAC地址？如何将金额转换成人民币的大写字符串？如何打印输出报表？等等。
l工作流调度组件，绝大部分业务应用都是程序化、有规范的作业流程，实现工作流调度组件可以降低对开发人员的要求，让一般开发人员在不懂得工作流系统的前提下开发基于工作流的应用。
3.6IBeamMDAA最终可达成的目标
前面分别从5个方面概要性的总结了开发企业级应用面临的挑战，软件开发企业虽然顶着高科持的帽子，却没有因为高科技使得大多数中小企业在行业中取得丰厚的收益，有些甚至入不敷出，最终破产倒闭，原因虽然复杂多样，但也有共同点：
l中小软件企业规模小，最初的资本是出资人的血汗钱，由于规模与可预见的发展前景对核心人才没有吸引力，自己辛辛苦苦培养的人才，一旦学成正果后马上离开企业，自己变成人才培训班，越是节省开支，越是经营困难。
l好不容易接到的项目，被新人拖延，利润全用于支出人员工资与办公费用上，代码写得乱七八遭，项目虽然完成了，没有赚得利润，还要承担起项目维护，往后的客户服务与软件升级实在不敢想，多少个夜晚都有杀人与被杀的冲动。
l几年下来，公司或个人都是筋疲力尽，对未来一片茫然。
总结，对于程序员的要求：如果不懂写程序，还不能模仿嘛？
注：软件开发也存在分工，有：软件架构师、需求分析师、程序员（程序编写人员），测试人员与客服人员。软件架构师、需求分析师的工作最有价值，程序员的工作是乏味的，测试与客服人员是不被重视的，要成为什么人完成取决于个人的选择与努力，只是中小企业中一个人同时担当了数个角色或者是全部角色。
哪么，您真得需要一个框架！
IBeamMDAA就是这么一个框架！
IBeamMDAA并不是一个全新的框架与系统，它建立在Csla.net的基础上，所有的概念都遵守Csla.net的约定，Csla.net就好像是内核，IBeamMDAA围绕其创建了系统的外围。整个框架中业务对象（移动对象DTO）在逻辑的各层中移动，协调运转，数据对象是数据库实体对象，只在数据访问层存在。下面是IBeamMDAA的三种基本结构，反映了IBeamMDAA从逻辑结构到物理结构的三种部署，但然，还有很多种变体结构，但都是从这三种基本配置变化而来。
以上图中“应用服务器”中运行着数据访问层与业务逻辑层，客户端里运行着业务逻辑层，这是典型的物理三层。业务对象在各层中传递。
以上图中，“数据服务器”里运行着数据访问层与业务逻辑层，应用服务器只运行着业务逻辑层，客户端运行着业务逻辑层。业务对象在各层中传递。
以上图中，没有所谓的“应用服务器”与“数据服务器”，客户端里运行着数据访问层与业务逻辑层，客户端直接连接数据库服务器。业务对象在客户端进程中执行。
如何选择配置取决于应用的需求，参见3.5.3节关于1-N层应用的配置，框架本身应提供这种伸缩能力，在应用部署结构变化时不用重新设计与修改原有代码。
4.1应用开发必备组件
序号
类库名称
版本
厂家
说明备注
1
IBeamMDAACore.dll
1.0.*
昆明光标科技有限公司
功能权限、界面定义注册属性，自动任务属性及工具类
2
IBeamMDAACommon.dll
当事人管理，界面、功能权限、系统设置，所有信息管理系统的基础
3
Castle.ActiveRecord.dll
3.0
Castle
依赖组件，ORM映射工具
4
Castle.Core
依赖组件
5
NHibernate
3.1
6
Iesi.Collections
1.0.1.0
7
Common.Logging
1.2.0.0
日志输出，依赖组件
8
log4net
1.2.10.0
9
XCrypt
1.0.0.0
通用加密组件
10
Csla.dll
3.8.4.0
MarimerLLC
11
Csla.XmlSerializers
4.2Winform开发必备组件（包含应用开发必备组件）
IBeamMDAAWinUI.dll
ComponentFactory.Krypton.Toolkit
4.3.1.0
ComponentFactory
UI基础组件
WeifenLuo.WinFormsUI.Docking
2.3.1.24483
WeifenLuo
界面依靠与布局
IBeamReportExporters
报表导出
HtmlHelp
0.4.1943.15286
Microsoft
从chm文件中读取Html文件
Microsoft.ReportViewer.Common
10.0.0.0
报表
Microsoft.ReportViewer.WinForms
4.3Web开发必备组件（包含应用开发必备组件）
.NetMVC
最新
DWZ
杜权(UI设计)duq@dwzjs.com
吴平(Ajax开发)rogerwu@dwzjs.com
张慧华(Ajax开发)zhanghuihua@dwzjs.com
4.4应用服务器Windows系统任务必备组件（包含应用开发必备组件）