随笔分类 - 架构与设计
摘要：一、引言
由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加。这样就会导致测试得到的信息不完整，以及后续产品的维护困难。在这里书写一份规范说明书，希望能得到一些改善。
二、目的
控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。
三、角色与职责
阅读全文
摘要：就像莎士比亚的“To be, or not to be, that is the question”始终困扰着哈姆雷特，对于“进程还是线程？”这个问题，也经常困扰着那些进行软件架构设计的家伙。所以今天打算聊一下我对这个问题的体会。假如你还搞不清楚线程和进程的区别，请先找本操作系统原理的书好好拜读一下，再回来看帖。
由于这个问题很容易引发口水战，事先声明如下：多进程和多线程，无法一概而论地说谁比谁好。因此本帖主要描述特定场景（与我所负责的产品相关）下，进程和线程的权衡经验，仅供大伙儿参考。
阅读全文
摘要：需求实践所面临的问题
需求完整性需要诸多用户的参与和确认，而且用户间需求本身也存在冲突的可能，因此需求更加强调角色和场景和划分，一个所有用户需要都能够满足的需求往往不是一个好需求。
需求过程缺乏用户的参与，我们往往是技术驱动，习惯性的跳到模块的划分导致需求本身验证困难，也导致了需求间耦合很紧，很难在后期组织有效的迭代开发。因此要考虑按流程和业务梳理需求。
需求无法实现也可能不是架构问题，而是需求本身不切实际。
用户想要和真正需要是有区别的，没有真正的识别需求优先级可能导致需求过量开发和需求镀金。
需求优先级识别往往并不能完全依靠用户，用户往往只会把自己关注功能讲优先级识别的很高，因此需求优先级识别应该是通过业务规则，流程和模式来确定。优先级识别方法(离主营业务的远近，发生的频率两个方面来度量)
沟通失真，要认识到文档仅仅是中介而不是全部，要通过即时的验证来减少沟通失真。
需求捕获和调研常见问题-用户告诉你的是他转化后的解决方案，而不是最原始的需求。
变更频繁，但是要响应变化，比如通过对变更分类来识别哪些变更是可以通过复用和可配置解决的。
非功能性需
阅读全文
摘要： 电子商务系统对安全问题有较高的要求，传统的访问控制方法DAC（Discretionary Access Control，自主访问控制模型）、MAC（Mandatory Access Control，强制访问控制模型）难以满足复杂的企业环境需求。因此，NIST（National Institute of Standards and Technology，美国国家标准化和技术委员会）于90年代初提出了基于角色的访问控制方法，实现了用户与访问权限的逻辑分离，更符合企业的用户、组织、数据和应用特征。ASP.NET是微软为了抗衡JSP而推出的新一代ASP（Active Server Pages）脚本语言，它借鉴了JSP的优点，同时它又具有自身的一些新特点。
本文将首先介绍ASP.NET的基本情况和RBAC（Role Based Access Control）的基本思想，在此基础上，给出电子商务系统中实现用户权限控制的一种具体方法。
阅读全文
摘要：前言
本文主要是对《ASP.NET 2.0开发指南》——章节内容的提取并略有补充。
参考资料
1. 《ASP.NET 2.0开发指南》
2. .NET 2.0 SqlDependency快速上手指南
支持数据库
SQL SERVER 7.0/2000/2005版本
阅读全文
摘要： 当开发者听到“设计模式”这个词时，他们通常联想到两个场景。一组开发者正在讨论许多创造性意见，正在开会，但是却没有进行编码。另外一组人能制定出正确的计划，保证系统能够开发成功，代码可以重用。
而现实一般都处于两者中间。在为他们的公司设计解决方案的时候，结构设计者和系统设计者应该寻找重复的模式。但是模式只是开发健壮、可重用代码的一个指导。结构设计者不能过多的去设计一个解决方案的结构，因为要定期交货。
阅读全文
