急！项目的架构问题
各位大侠，请问我现在在开发一个牙医的绘图软件(C/S)，最初的版本功能比较少，但接下去的版本功能上会有很多的增加，我现在想用三层架构，请问适合吗？如果不使用有什么好的提议吗？比较急！！！

------解决方案--------------------
可以从时间上考虑，如果时间允许，那MVC是不二选择，
如果不允许，那去掉一层提高开发效率也可
------解决方案--------------------
一、什么是三层结构 
在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或成为领域层）、表示层. 

二、三层结构的优点 
1、开发人员可以只关注整个结构中的其中某一层； 
2、可以很容易的用新的实现来替换原有层次的实现； 
3、可以降低层与层之间的依赖； 
4、有利于标准化； 
5、利于各层逻辑的复用。 

概括来说，分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。 

一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如UI人员只需考虑用户界面的体验与操作，领域的设计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认，开发进度就可以迅速的提高。 

松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。每个功能模块一旦定义好统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。 

进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。 

三、分层式结构缺陷： 
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。 
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。 

这是别人的观点,但我觉得概括得很全面了,供楼主参考
------解决方案--------------------
看的情况。

如果时间足够，重构是必须的。

如果时间来不急，可以考虑优先开发插件系统，以便扩展。或者发布成智能客户端的形式（智能客户端到是一个暂时性替代方案的不错选择，不过有机会重构的话，还是尽量重构先）
------解决方案--------------------
学习~~顶~~~~~~呵呵
------解决方案--------------------
推荐楼主看看PDF.NET 快速（数据）开发框架，下载一个演示程序，里面有多层架构的例子。
文章地址：
http://blog.csdn.net/bluedoctor/archive/2010/01/24/5251913.aspx
------解决方案--------------------
如果没有和数据库打交道，可以把数据访问层省掉。如果业务这块很复杂，也可以适当多分几层。这个是很灵活的。
------解决方案--------------------
路过，路过

学习中
------解决方案--------------------
做好架构设计其实很难，难点在于它要适应需求的千变万化，而不可能是一开始就给你一个签一个保证不变的合同。

你懂业务，已经能够用软件的术语来说清楚许多想法，这就够了。下一步需要做的事，拉近跟真正架构师的居住的“距离”，比如首先租个办公室或者旅馆几天，好好研究一下合作的可能性。
------解决方案--------------------
意思就是让你找牛人合作。
------解决方案--------------------
这个东西 还是经验的优势体现出来了