一、开发基础选用

            软件免费版开发基础包括数据访问，监控跟踪，异常处理，日志记录，公共函数等东西，每个系统一般都不是从零开始做的，都有个基础架构的，有的可能功能少一些，但是数据访问是必须的，我列举一下备选的方法供大家讨论。

            1、听堂的SPL

            评价：简单易用，功能也不弱，能有效提高开发效率，但是处理存储过程上还有些缺乏自动化，而且我感觉有点儿争议的是它没有返回IDataReader的接口是不是个缺陷，当然作者有自己的考虑。

            2、双鱼座的Kanas.Net

            评价：双鱼的这个东西我是在好几年前CSDN的帖子里看到的，功能很全面，也不知道他让不让用，估计采用的话学习成本会提高。CSDN的那个帖子地址如下，里面有几个人对ORM的讨论

            3.《ASP.NET电子商务高级编程》里凯文.霍夫曼写的.NETCMP框架

            评价：可以有效减少代码数量，错误处理，检测跟踪也都集成了进去，是一个很灵活的框架，存储过程处理非常方便，而且使用了托管容器的概念，使业务层代码可以不关心数据访问层的代码。

            评价：有配套的代码生成器，功能很强大，能生成好多代码，在项目里同步一下就可以更新，自动生成的CRUD操作和对存储过程的操作都考虑的很周全，数据访问默认已经支持了并发处理和多层处理，可以方便remoting的调用。内置性能计数器等处理。

            5.微软的EL

            DAAB大家都很熟悉了，但是我却没怎么用过，微软的这套应用程序块使用了策略的模式，使用起来很方便，耦合性也小，但在开发效率上不如以上几个框架考虑的多感觉。

            二、架构选择

            为了保证软件最终的可伸缩性，打算使用多层架构来开发。业务层代码，表示层，数据库层都可以分别运行在不同的机器上。表示层可以使用智能客户端，WEBFORM,移动工具等，业务层以remoting和webservices形式发布，数据库采用mssqlserver。

            具体我是这样考虑的像需要报表，图表，以及管理的功能都做成智能客户端来实现，因为这些功能用浏览器来实现需要费很大的周折，我的意思是对使用这些功能的客户部署一个引导的小程序，也就是applicationbrowser,然后这个应用程序浏览器通过一个web服务来获取可用的功能，以及执行这些功能的程序集的位置，从一台单独的web服务器上下载程序集缓存到本地来执行客户端逻辑。这样给这些客户端发布新功能的时候可以更改这个web服务，通过这个web服务像智能客户端发布新功能，自动下载，执行。这些桌面程序执行的时候是远程创建remoting对象，然后调用这些对象的方法，而remoting对象可以驻留在另一台单独的应用程序上。

            然后大多数功能通过asp.net来实现，asp.net的web服务器也是调用remoting服务器上的对象来运行业务逻辑，然后生成通过webform来和客户进行交互。

            还需要一个移动应用程序，每个客户可以通过PDA或其它设备查看自己的客户，以及客户的手机，住址等信息，方便他们用移动工具沟通，加大销售的机会。

            基本上架构上我就是这样考虑的，当然所有的服务可以在一台机器上运行，但是也为以后扩展提供可伸缩性。

            三、身份验证和授权

            因为程序本身支持多界面，所以我打算身份验证用一个web服务来执行，这样在桌面程序，asp.net，移动控件都可以调用web服务来进行身份验证并获取令牌，令牌也可以串行化并在层间传递，当然这样的话需要用到xml签名,xml加密，对客户端IP验证等一些列增强安全性的措施。

            四、管理

            管理工具分为两种，一种是对业务的管理，比如修改权限，添加产品，添加客户等，这些管理功能最好是使用windows验证方式在局网内进行管理，或者是使用webform远程管理的话需要使用一些增强的安全性，比如说https等。还有一种管理是对remoting服务器的跟踪和管理，比如停止windows服务，查看对象实例化的个数等。这些管理行为想做个桌面程序来管理服务进程，使用那个那个什么singleg模式，好像叫单件模式，这样可以远程停止，启动，查看remoting的运行装款以及windows服务。最好是可以集成到微软的MMC里面

            五、合理使用代码生成器，第三方控件，模块，工具

            比如说nunit,nant这类的东西最好能利用起来，懒是程序员的美德，能省事咱就省事，当然是保证安全和质量的情况下。控件方面也尽量用已经可用的控件，不自己开发。模块呢，像身份验证啦这些都是通用的，可以拷贝一些代码进来，进行测试后投入使用。代码生成器大多灵活性不够，可以使用我的wawacodepro或者其它有些支持模板的代码生成器来减少重复性代码的手工输入。

            六、自动化处理，异步处理，分布式事务管理

            因为使用了多层架构，就得考虑到网络阻塞的情况，所以我们得使用一些异步处理方式以及自动化处理程序，比如说把添加的客户生成的数据先串行化成xml，然后保存在一个目录里，然后通过一个windows服务监视这个目录处理里面的XML数据并放入数据库里，使用一些重试队列来处理意外情况，如果加入重试队列2次以上就放入停止队列里面。这种方法经常用在订单处理里面，我们需要的话也可以把部分逻辑使用这个方法处理。如果到时候架构很复杂的话需要用一些分布式事务管理,来保证业务数据的完整性，这个先考虑进去。

            七、自动部署和代码访问安全

            这是.NET的特性，使用了智能客户端，这些都要考虑一下，不能为了使用智能客户端而增加了部署的麻烦和降低了安全级别。

            八、计数器

            这些东西要集成到管理工具里面，一般使用.NET的特有的几个计数器就可以，主要死活用性能（资源）计数器，用量计数器，频率计数器，这些在构建.netremoting对象的时候需要加进去，可以让管理工具查看某个remoting方法一分钟调用了多少次，某个remtoing对象有多少个实例，可以查看CLR运行占用的资源等

            九、异常报告，事件日志，调试跟踪，负载平衡

            如果是在智能客户端上发生了异常要把异常用web服务或者电子邮件发送到异常管理人员，如果是服务器上发生了异常也要用web服务把异常报告到集成的地方，我认为web服务来报告异常是很好的，智能客户端可以加入一些在线崩溃分析的功能，报告异常的时候另外要报告一些额外的信息，比如说当前windows登陆用户名，磁盘剩余控件，进程ID等信息，便于分析人员分析鼓掌原因。

            使用事件日志是一种过时的技术，还需要人为的去查看错误记录。但是我们可以双管齐下，日志可以让系统管理员得到一些帮助。

            在开发阶段debug是很有用的，可以帮助开发人员分析程序为什么出错，而trace是程序正式运行后出现了问题，可以启用跟踪来查看变量的输出，用来分析程序的运行情况，这些都要考虑进去。

            最后负载平衡，我想要对循环法给予支持，因为只需要几行代码就可以实现。而对单点故障法暂时不用考虑，因为需要applicationserver或者硬件的支持

            十、最后是易用性问题

            为了提高用户体验，在界面设计上要多为客户考虑一些，颜色，布局，使用方便，每日提示，帮助，状态栏提示，习惯性调查，使用首选项等都要提供。

            基本上就是这些吧，我明天要回乡下，参加项目的朋友先看看我的方案，给点儿意见。