发表评论
没什么能帮忙的，从精神上支持一下吧！
重构的道路肯定是很艰辛的，各位辛苦啦
看了留下的留言，有几点想补充：
1、能不能写一些文字性的说明，让大家更加明白，不然理解起来可能有歧意。
2、支持多数据源，既然有这个想法，就做出来，确实费不了多少事。
3、数据库的架构模型有没有，能不能也发出来。是用一个库还是多个库协同。
我现在每天都要来博客园看看大家的东西呢
学到了不少
谢谢
我现在每天都要来博客园看看大家的东西呢
学到了不少
谢谢
1 为什么每一层都需要接口？
2 需要用SQL Server和Oracle两种数据库么？
3 是重购还是重写？个人感觉还是重写比较好一些，重构的遗留问题太多了
数据库没必要支持oracle或xml,只接支持sql就好了.
#14楼 [
楼主]2008-03-20 11:21 |
@Jeffrey Zhao
Service Layer相当于业务外观层。
#18楼 [
楼主]2008-03-20 11:56 |
@Dflying Chen
@lzppcc
现在考虑多数据库的支持，增加不了多少工作量。如果现在不考虑，以后要改为多数据库支持的成本就很高。
Service Layer作为业务外观层
可减少表现层和业务逻辑层的耦合
另外业务逻辑层貌似不太用到接口
这个地方跟业务实体不用接口类似
我的主意是搞成Facebook App那种，让用户自己满足自己的需求，网站提供基础服务就行了。
如果真能这样我愿意捐献几个man month，把豆瓣clone过来。
如果能把整个开发的过程单独开个版块给记录下来那就爽了
叫做：开发日志啥的。。。
跟我现在做的eip差不多，但是我没有用到 service layer,cache，表现层没你那麽复杂，不过我的eip现在正在往上加workflow ，o(∩_∩)o...，加油吧，改好通知一下，好向你学习。
如果要考虑多数据库的支持，不知道为什么不用Nhibernate,毕竟Ibatis虽然灵活，但是如果要更换数据库，工作量相比Nhibernate要多很多。
不知道DUDU是否有其他的考虑？
还有就是表现层与服务层的解耦，建议使用Castle.Net来管理。实现简单的依赖注入，我觉得Castle要比Spring.net要简洁一些。
使用wcf提供REST风格的 API供第三方调用
另外建议可以使用db4o做中间缓存
怎么好像有点petshop的风格，过多的分层会不会有效率问题呢。
嗯 和 微软的那个网上书店架构差不多!
多结合博客园自身需求来设计架构
我个人认为重构比较好，毕竟要考虑博客长远的发展。
不然以后将会是一件更痛苦的事.........
然后就是不明白为什么每一层都有接口定义？
还有就是提个建议：如果可以的话，将整个博客的实施过程和开发日志做一个博客？
把service 单独成一个layer,是不是有点过了?要不就单独抽出来,要不就跟web layer平行了,放web layer下面，有点过了吧?
Web层可采用ASP.NET MVC,估计重构完它也Release了，中间层采用WCF比较好，WCF支持单台服务器的时候就是进城内的，多台的负载环境就是分布式的，而且WCF是一个统一的编程模型。
数据访问层用NBear不错，是cnblogs上的自有技术。
学到很多啊.......刚开始在架构上学习........受益..........
presentation层的winform能换成wpf么....
感觉还是重写比较好，重构中肯定会感觉束手束脚的。
其实大面积重构的工作量并不比重写小，制约却大了很多
博客园又要向前发展了，呵呵
不过有几个地方没看明白
1、 Service Layer，什么叫业务外观？
2、 DAL中的，比如iBatis这样的东西对数据库的依赖很大的，如何用以实现数据库透明呢？
3、怎么到处都是接口？要工厂？还是准备日后做API？
真正等你换数据库的时候
估计 你的 整体 架构都得 再次 重构了...
支持多数据库 对于一个 网站项目 没有什么意义
我们的网站从04年存在，经历了无数人的蹂躏，不管数据库和代码都是乱的一塌糊涂。。。号称最近要升级到2.0（目前是1.1），难啊。
mvc+linq+ado.net ef+silverlight+asp.net ajax+wcf+wf+utility+一系列开源框架 爽阿
如果在博客园重构完成后发些相关的开发过程文章，这样是可以的，但是如果要边开发边发布开发过程文章，开发人员哪有那么多的时间和精力。
个人感觉，现在的架构基本上符合了，顶多关键是service layer怎样和表示层怎样分配结合了，到底是做成soa还是什么的形式，还有在各个层当中不见得就一定要用当前常用的ioc和orm框架，关键是考虑性能还是考虑后期维护。
@lovecherry
--引用--------------------------------------------------
lovecherry: mvc+linq+ado.net ef+silverlight+asp.net ajax+wcf+wf+utility+一系列开源框架 爽阿
--------------------------------------------------------
so great,so powerful.
建议DUDU使用Remoting...如果不考虑平台的话。
Remoting为前端Webform和Winform提供支持。
Remoting分布式布署是蛮不错的选择。如果cnblogs做大的话。
强烈建议dudu开源，这样园子里的兄弟们都可以贡献一份自己的力量！
ps: 开源对项目管理和架构的要求很高（有点怕怕）:)
我觉得service layout & Business logic layout不应该用interface来实现,应该用facade method(外观模式)来实现,interface只不过是method的抽象,如果你的business很复杂的话,这个interface岂不是太大了?日后的maintainence就会变得很麻烦.
1,BL interface layer有什么作用？似乎有点多余。
2,各个模块/子系统间如何进行交互/集成。你的架构图太简单了，只有纵向层次结构，没有横向模块结构。
3，同上，图画的太简单了，没有表现出层次间的通信。主要是service consumer和service provider之间的通信，有哪些通信方式？各针对什么类型的consumer,应该画清楚。
4，cache画这么大？意思所有对business的访问都要经过cache?
#36楼 2008-03-20 13:24 自由、创新、研究、探索……
Web层可采用ASP.NET MVC,估计重构完它也Release了，中间层采用WCF比较好，WCF支持单台服务器的时候就是进城内的，多台的负载环境就是分布式的，而且WCF是一个统一的编程模型。
=======================
“WCF支持单台服务器的时候就是进城内的，多台的负载环境就是分布式的“这个话何解？统一的编程模型主要含义还是统一的"远程"访问编程模型。
关于这个我觉得dudu的设计就足够好了，有了一个service interface就有了足够的灵活性，至于具体的是in-proc的 实现还是wcf的实现都是可扩展的。
如果我写的话就一定用MVC fw了，之前要准备拉一批美工和专门写js的人才。
至于数据库lz的设计显然有些迷茫，xml不能作为一个数据库。
还有一个至关重要的一点，lz把层分的这么细致，代码的严谨要求会指数式的增加，到最后会很难控制代码质量，直到得到一个可用却不理想的重构版。
工期多长？
做个网站可真不容易，我觉得性能不成问题的话，就优化一下可读性就OK了。
先给出一个能用的版本，然后在这之上一点点给出进步，别一下想太多，过度设计跟没有设计带来的后果差不多，可能更甚之。
至于数据库我觉得你真的想太多了，sql server难道不够你用？等不够用的时候，真正应该操心的可能就不是数据库了。
COM+!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
高性能、分布式网站的不二选择
很好，比csdn好多了，csdn对服务好像不是很讲究，经常用的很不爽
WCF、COM+什么都不需要。博客园有多少业务运算呢？为什么要多加一个应用层？直接Web服务器+数据库服务器对于大部分互联网应用来说就可以了，多加一层反而降低性能，本来就没有什么计算任务，还增加了通信成本。
当然，如果博客源想释放API的话，那么WCF是不二的选择。
还有就是，分布式数据库是可以考虑进去的，但是我也觉得多种类型数据库倒真没有什么必要……
@Jeffrey Zhao
多库分布是必须要考虑进去的，如果没有多库，则没有必要搞的那么复杂。最终的难题，我估计应该会在多库分布这个核心点上面。
多数据库支持完全没必要做,一开始选好要用什么库就好了.
分库通常也没意义,做好数据库的负载就好,再把缓存做好就足够.
这种分层只是形式，接口/类/代码量会带来无谓的复杂性和工作量，并不见得维护性能得到改善
大型网站程序这样做的应当比较少，性能(包括缓存方案)、伸缩性是两大关键，把这两项设计好就OK，其它用最快捷的方式实现，中间每引入一个框架可能意味着开发过程以及维护阶段要面临很多问题
两个想法
1. dotext好像把文章存数据库了，这样带来的性能瓶颈太大，可以考虑文章只存为文件，用lucence做搜索
2. blog系统比较好实现线性伸缩，可以在这方面多考虑
进来学习，现在还插不上话。
希望有朋友可以介绍一下多库分布
關注
重構是一項大的工程
需求會一直變動,技術也在不斷翻新,或者在目前的專案上去精簡代碼,實現可擴展性的新需求
@dudu
可以将文章以xml形式存放，然后用xslt,xsd对xml进行约束、修饰、展现。
如果是大刀阔斧的重构，考虑多数据库支持还是必要的，要不然以后的维护会有更多麻烦。
整体的架构还是很经典的，在传统三层架构上，隔离出服务层，我认为基于以后的需求扩展考虑也是应该，WCF绝对是不错的选择。不过正如老赵所说，增加通信成本是无疑的。
某些精妙的实现可以考虑部分开源，我喜欢service layer
业务外观层有没有必要？
难道所有业务都需要外观？
业务层也要全部抽象出Interface吗？有什么用？这点我比较奇怪
复杂了点，有点过度设计
针对用户体验和性能多设计一下吧，博客园业务倒不是那么复杂的！
感觉鲜果的模式还不错，有自己的一套digg机制，
好文章看的人多顶的人也多，自然而然就区分出精华了。
前期的需求分析真的重要。
可扩展性，伸缩性，性能，用户体验很多都需要考虑的很清楚。
博客园开发团队辛苦了~一如既往的支持博客园~
--引用--------------------------------------------------
lxinxuan: 我们的网站从04年存在，经历了无数人的蹂躏，不管数据库和代码都是乱的一塌糊涂。。。号称最近要升级到2.0（目前是1.1），难啊。
--------------------------------------------------------
比你惨！
我的一个OA系统是一个大工厂集团03年上线的，.net 1.1的，历经公司N代程序程序员的修改，里面的功能早就脱离的 OA系统的范畴，系统没有分层，没有架构，所有的逻辑杂到一起，就着个烂系统，支撑这一个上百千亿营业额的工厂，，
目前就我一个人维护，，最近猛然听说要重写，但要保持原有的数据和所有功能，，，我的娘，我一听头就大，浑身冒汗！
可以将文章以xml形式存放，然后用xslt,xsd对xml进行约束、修饰、展现。
这样seo效果不好。
多数据库设计是愚蠢的。整个程序不支持几个数据库就好像不是程序是的？博客园一共的贴子有六七十万没？贴子内容存在文件内，标题啥