最近客户跟不上我开发的系统思路，只要对系统降级。从分布式下降到统一网站处理。
过程中，我在思考，这种工作如何才能不重复？
现状：
门店系统，分布在不同的店铺；网站；后台服务器。
三大系统，各自负责对应的功能，或许会有部分的逻辑重叠。现在的问题是，如何设计架构。
问题一：三大系统使用通用的dll类库。
首先这个方式可以否定。虽然大家各自有逻辑重复，但是具体的实现却有细微差别。
例如网站创建商品，后台服务器创建商品，由什么去创建这个是有差别的。
虽然目前似乎是直接输入参数，方法去创建；但是未来可能扩展到通过表单审批创建等等。这种业务层次的逻辑不可能统一。
结论：各自系统维护格子系统的业务逻辑代码。
问题二：在业务领域是否需要分层次。
我以前经常把业务代码写在controller，但是到了后来发现，这种controller根本没有重用的价值，基本上一个页面只会对应一个controller。
即使有重用，也是因为页面发生了重用，而不是多个页面公用相同的controller。
结论：controller要针对业务，而不是针对重用。
问题三：controller是否必要？还是说放在codebehind里面？
在codebehind里面，会有很多和页面交互的事件，如果把controller也放在这里地方，维护的时候会比较臃肿。如果放在单独的文件夹，维护又会麻烦，毕竟一个page对应一个controller。
解决方法：使用partial class. 在c#里面，通过嵌套，可以实现逻辑代码也页面代码捆绑。
http://topic.csdn.net/u/20091203/11/77aa403d-3e11-40c2-bda8-1ee199ce8850.html
<ItemGroup><Compile Include="uip.cs">
</Compile>
<Compile Include="uip.m1.cs">
<DependentUpon>uip.cs </DependentUpon>
</Compile>
在asp.net里面，必须放在单独的文件夹。
结论：和业务相关的代码使用partial。不另外开controller。
根据以上问题，最后回到一个方法：
代码设计过程是没有问题，从文档、思路、抽象、大纲，到具体的代码片段。
问题是，有了代码之后，隔一段时间需要再维护，这个时候的学习成本非常高。
很多时候，实际代码和开发过程的文档有很大出入。如果有个工具可以链接两者，可以从代码去修改原有的设计文档，这样就非常方便了。
2010-04-03 再次更新思路
各自系统维护格子系统的业务逻辑代码，系统之间不重用业务代码。
controller要针对查询，不处理业务。controller的划分根据查询对象不同划分。
和业务相关的代码使用partial。如果在asp.net，则在相同文件新开一个partial class。