关于模式的探讨

对于一个大项目来说，不可能在开发之前对所有的细节都考虑得很周到，你要做的首先是和客户把所有的需求都了解透彻，形成需求分析文档，尽可能详细些并且不要提太多技术方面的内容，有可能的话可以先画个界面的草图，然后让客户确认，这不是教条而是对自己的一种保护，因为客户很有可能在中途变更需求，如果真有这种情况，你可以拿着当初他确认过的需求说事，加价或加时间。
在吃透了需求以后，得考虑系统怎么搭，应该是一些框架性的东西，考虑好需要用到哪些技术，这些技术之间要怎么衔接，如果没有现成的技术还需要自己先做一些功课。在这个阶段，最好也能形成文档，把能考虑到的问题都写下来，特别是一些业务规则，不过这是给自己看的，所以可以写得随便些，这个文档可以很好地帮助你在后续开发的过程中把握主干，不至于越往后开发越偏离方向。
除非你有很严重的强迫症，否则千万不要过于教条，例如N层架构、模式什么的，至于LZ说的面向对象编程，真的不要太在意，因为C#本身就是一门面向对象的语言，从使用它的第一天起你已经被面向对象了。不过底限得把握住，我的底限和原则是：
1、绝对不在界面层的DLL里写业务处理逻辑。
2、绝对不在界面层的DLL里进行直接的数据访问，甚至不引用System.Data这个DLL。
3、绝对不在业务逻辑层对界面进行干预，绝对不引用System.Web或System.Windows.Forms这些用于界面的DLL。
4、对功能类似的代码尽可能避免写在两个地方，应该把相同的部分抽象出来，利用参数或面向对象的多态特性进行重载来实现不同的需求。




1，先把项目彻底的分析一遍
2，找出其中的技术问题和关键点
3，去网上找一些优秀的框架，学习。
4，对于数据库，良好的设计规范，多用存储过程，触发器，之类的
5，规范的命名
6，多问，勤学
7，做好项目规划和进度安排




最基本的，你操作的实体，基本是对应的数据库表，关联表也可以是主表的属性实体






所以你会看到，很多“某鸟”的学员，拿着那种毫无价值的小案例把设计模式上的例子颠三倒四地做来做去，为什么呢？他对于这些设计模式运用的场合完全没有一点概念，在他的认知中也没有什么可以类比的东西，他的认知是停留在代码层面的，他选择性地记住了那些代码如何变幻，怎么定义几个接口传来传去这些表面文章。