dudu

评论

#101楼 2008-03-20 11:16 Dflying Chen      

1 为什么每一层都需要接口？
2 需要用SQL Server和Oracle两种数据库么？
3 是重购还是重写？个人感觉还是重写比较好一些，重构的遗留问题太多了   回复  引用  查看    

#102楼 2008-03-20 11:18 lovecherry      

架构也就这样了，细节更重要   回复  引用  查看    

#103楼[楼主] 2008-03-20 11:21 dudu      

@Jeffrey Zhao
Service Layer相当于业务外观层。   回复  引用  查看    

#104楼 2008-03-20 11:21 lzppcc[未注册用户]

数据库没必要支持oracle或xml,只接支持sql就好了.   回复  引用    

#105楼 2008-03-20 11:29 ppchen（陈荣林）      

懂得不多，纯支持一下！   回复  引用  查看    

#106楼 2008-03-20 11:46 Anders Cui      

@lovecherry
还有哪些细节，详细点？   回复  引用  查看    

#107楼 2008-03-20 11:49 狼Robot      

支持.   回复  引用  查看    

#108楼[楼主] 2008-03-20 11:56 dudu      

@Dflying Chen
@lzppcc
现在考虑多数据库的支持，增加不了多少工作量。如果现在不考虑，以后要改为多数据库支持的成本就很高。   回复  引用  查看    

#109楼 2008-03-20 11:56 Clark Zheng      

重构，阵痛   回复  引用  查看    

#110楼 2008-03-20 12:04 Anders Cui      

Service Layer作为业务外观层
可减少表现层和业务逻辑层的耦合

另外业务逻辑层貌似不太用到接口
这个地方跟业务实体不用接口类似   回复  引用  查看    

#111楼 2008-03-20 12:04 yushih      

我的主意是搞成Facebook App那种，让用户自己满足自己的需求，网站提供基础服务就行了。
如果真能这样我愿意捐献几个man month，把豆瓣clone过来。   回复  引用  查看    

#112楼 2008-03-20 12:27 winzheng      

不错，早重构，早安心。。。   回复  引用  查看    

#113楼 2008-03-20 12:29 overred      

如果能把整个开发的过程单独开个版块给记录下来那就爽了
叫做：开发日志啥的。。。
  回复  引用  查看    

#114楼 2008-03-20 12:29 反对方的反对[未注册用户]

跟我现在做的eip差不多，但是我没有用到 service layer,cache，表现层没你那麽复杂，不过我的eip现在正在往上加workflow ，o(∩_∩)o...，加油吧，改好通知一下，好向你学习。   回复  引用    

#115楼 2008-03-20 12:43 路过[未注册用户]

如果要考虑多数据库的支持，不知道为什么不用Nhibernate,毕竟Ibatis虽然灵活，但是如果要更换数据库，工作量相比Nhibernate要多很多。
不知道DUDU是否有其他的考虑？
还有就是表现层与服务层的解耦，建议使用Castle.Net来管理。实现简单的依赖注入，我觉得Castle要比Spring.net要简洁一些。   回复  引用    

#116楼 2008-03-20 12:43 t[未注册用户]

使用wcf提供REST风格的 API供第三方调用　
另外建议可以使用db4o做中间缓存
  回复  引用    

#117楼 2008-03-20 12:44 t[未注册用户]

多数据库支持用subsonic方便   回复  引用    

#118楼 2008-03-20 12:48 生鱼片      

怎么好像有点petshop的风格，过多的分层会不会有效率问题呢。   回复  引用  查看    

#119楼 2008-03-20 12:59 KevinLi      

嗯 和 微软的那个网上书店架构差不多!
多结合博客园自身需求来设计架构   回复  引用  查看    

#120楼 2008-03-20 13:05 Shiherpoo      

我个人认为重构比较好，毕竟要考虑博客长远的发展。
不然以后将会是一件更痛苦的事.........
然后就是不明白为什么每一层都有接口定义？
还有就是提个建议：如果可以的话，将整个博客的实施过程和开发日志做一个博客？   回复  引用  查看    

#121楼 2008-03-20 13:05 Shawn Ji      

不基于.Net3.5么   回复  引用  查看    

#122楼 2008-03-20 13:09 后台运行中[未注册用户]

把service 单独成一个layer,是不是有点过了?要不就单独抽出来,要不就跟web layer平行了,放web layer下面，有点过了吧?   回复  引用    

#123楼 2008-03-20 13:09 EricWen      

很关注
希望能给出更详细的说明。
  回复  引用  查看    

#124楼 2008-03-20 13:12 阿不      

感觉有些地方过于冗余了。   回复  引用  查看    

#125楼 2008-03-20 13:21 后台运行中[未注册用户]

顺便问一下,这个图是用什么工具画的???   回复  引用    

#126楼 2008-03-20 13:24 自由、创新、研究、探索……      

Web层可采用ASP.NET MVC,估计重构完它也Release了，中间层采用WCF比较好，WCF支持单台服务器的时候就是进城内的，多台的负载环境就是分布式的，而且WCF是一个统一的编程模型。
数据访问层用NBear不错，是cnblogs上的自有技术。   回复  引用  查看    

#127楼 2008-03-20 13:48 高_超      

学到很多啊.......刚开始在架构上学习........受益..........   回复  引用  查看    

#128楼 2008-03-20 13:57 Da Vinci      

presentation层的winform能换成wpf么....   回复  引用  查看    

#129楼 2008-03-20 13:57 Zhuang miao      

有那时间不如重写！支持重写...重写个更强大的   回复  引用  查看    

#130楼 2008-03-20 14:02 airwolf2026      

呵呵.刷新看看.   回复  引用  查看    

#131楼 2008-03-20 14:04 老Q      

感觉还是重写比较好，重构中肯定会感觉束手束脚的。
其实大面积重构的工作量并不比重写小，制约却大了很多   回复  引用  查看    

#132楼 2008-03-20 14:07 Evernory      

工程浩大啊~   回复  引用  查看    

#133楼 2008-03-20 14:10 电机拖动      

博客园又要向前发展了，呵呵
不过有几个地方没看明白
1、 Service Layer，什么叫业务外观？
2、 DAL中的，比如iBatis这样的东西对数据库的依赖很大的，如何用以实现数据库透明呢？
3、怎么到处都是接口？要工厂？还是准备日后做API？   回复  引用  查看    

#134楼 2008-03-20 14:22 ludao[未注册用户]

真正等你换数据库的时候
估计 你的 整体 架构都得 再次 重构了...

支持多数据库 对于一个 网站项目 没有什么意义   回复  引用    

#135楼 2008-03-20 14:39 Kai.Ma      

这图用什么软件画的，推荐个   回复  引用  查看    

#136楼 2008-03-20 14:45 Netprawn      

用WORD应该就可以画.支持一个   回复  引用  查看    

#137楼 2008-03-20 14:45 lxinxuan[未注册用户]

我们的网站从04年存在，经历了无数人的蹂躏，不管数据库和代码都是乱的一塌糊涂。。。号称最近要升级到2.0（目前是1.1），难啊。   回复  引用    

#138楼 2008-03-20 14:46 lxinxuan[未注册用户]

补充：我们网站pv几百万，不是吹的，确实是这样。   回复  引用    

#139楼 2008-03-20 14:48 lovecherry      

mvc+linq+ado.net ef+silverlight+asp.net ajax+wcf+wf+utility+一系列开源框架 爽阿   回复  引用  查看    

#140楼 2008-03-20 14:57 Dove.Net      

真是好消息支持   回复  引用  查看    

#141楼 2008-03-20 14:58 alvin（我就是我）[未注册用户]

如果在博客园重构完成后发些相关的开发过程文章，这样是可以的，但是如果要边开发边发布开发过程文章，开发人员哪有那么多的时间和精力。
个人感觉，现在的架构基本上符合了，顶多关键是service layer怎样和表示层怎样分配结合了，到底是做成soa还是什么的形式，还有在各个层当中不见得就一定要用当前常用的ioc和orm框架，关键是考虑性能还是考虑后期维护。   回复  引用    

#142楼 2008-03-20 14:58 Vincent Jiang‎      

@lovecherry
--引用--------------------------------------------------
lovecherry: mvc+linq+ado.net ef+silverlight+asp.net ajax+wcf+wf+utility+一系列开源框架 爽阿
--------------------------------------------------------
so great,so powerful.   回复  引用  查看    

#143楼 2008-03-20 15:25 RandyTse[未注册用户]

建议DUDU使用Remoting...如果不考虑平台的话。
Remoting为前端Webform和Winform提供支持。   回复  引用    

#144楼 2008-03-20 15:25 不知如何爱你      

現在正在 研究架構，學習下，頂！！！   回复  引用  查看    

#145楼 2008-03-20 15:26 RandyTse[未注册用户]

Remoting分布式布署是蛮不错的选择。如果cnblogs做大的话。   回复  引用    

#146楼 2008-03-20 15:32 andy.wu      

强烈建议dudu开源，这样园子里的兄弟们都可以贡献一份自己的力量！

ps: 开源对项目管理和架构的要求很高（有点怕怕）:)   回复  引用  查看    

#147楼 2008-03-20 15:45 lbq1221119      

海不错，就是感觉不够详细
这个图还是远远不够的   回复  引用  查看    

#148楼 2008-03-20 16:22 vincent-shi[未注册用户]

我觉得service layout & Business logic layout不应该用interface来实现,应该用facade method(外观模式)来实现,interface只不过是method的抽象,如果你的business很复杂的话,这个interface岂不是太大了?日后的maintainence就会变得很麻烦.   回复  引用    

#149楼 2008-03-20 16:46 Wind Snail      

1,BL interface layer有什么作用？似乎有点多余。
2,各个模块/子系统间如何进行交互/集成。你的架构图太简单了，只有纵向层次结构，没有横向模块结构。
3，同上，图画的太简单了，没有表现出层次间的通信。主要是service consumer和service provider之间的通信，有哪些通信方式？各针对什么类型的consumer,应该画清楚。
4，cache画这么大？意思所有对business的访问都要经过cache?   回复  引用  查看    

#150楼 2008-03-20 16:53 Wind Snail      

#36楼 2008-03-20 13:24 自由、创新、研究、探索……
Web层可采用ASP.NET MVC,估计重构完它也Release了，中间层采用WCF比较好，WCF支持单台服务器的时候就是进城内的，多台的负载环境就是分布式的，而且WCF是一个统一的编程模型。

=======================
“WCF支持单台服务器的时候就是进城内的，多台的负载环境就是分布式的“这个话何解？统一的编程模型主要含义还是统一的"远程"访问编程模型。

关于这个我觉得dudu的设计就足够好了，有了一个service interface就有了足够的灵活性，至于具体的是in-proc的 实现还是wcf的实现都是可扩展的。   回复  引用  查看    

#151楼 2008-03-20 17:37 A.Z      

如果我写的话就一定用MVC fw了，之前要准备拉一批美工和专门写js的人才。
至于数据库lz的设计显然有些迷茫，xml不能作为一个数据库。
还有一个至关重要的一点，lz把层分的这么细致，代码的严谨要求会指数式的增加，到最后会很难控制代码质量，直到得到一个可用却不理想的重构版。
工期多长？

  回复  引用  查看    

#152楼 2008-03-20 17:56 蛙蛙池塘      

做个网站可真不容易，我觉得性能不成问题的话，就优化一下可读性就OK了。   回复  引用  查看    

#153楼 2008-03-20 19:00 whoami[未注册用户]

先给出一个能用的版本，然后在这之上一点点给出进步，别一下想太多，过度设计跟没有设计带来的后果差不多，可能更甚之。

至于数据库我觉得你真的想太多了，sql server难道不够你用？等不够用的时候，真正应该操心的可能就不是数据库了。   回复  引用    

#154楼 2008-03-20 19:24 破曉之陽      

加油。。   回复  引用  查看    

#155楼 2008-03-20 20:32 针式个人知识库管理      

COM+!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
高性能、分布式网站的不二选择   回复  引用  查看    

#156楼 2008-03-20 20:40 没剑      

歌太好听了~~
dudu努力   回复  引用  查看    

#157楼 2008-03-20 21:27 酷勤网[未注册用户]

很好，比csdn好多了，csdn对服务好像不是很讲究，经常用的很不爽   回复  引用    

#158楼 2008-03-20 22:22 Jeffrey Zhao      

WCF、COM+什么都不需要。博客园有多少业务运算呢？为什么要多加一个应用层？直接Web服务器+数据库服务器对于大部分互联网应用来说就可以了，多加一层反而降低性能，本来就没有什么计算任务，还增加了通信成本。
当然，如果博客源想释放API的话，那么WCF是不二的选择。   回复  引用  查看    

#159楼 2008-03-20 22:26 Jeffrey Zhao      

还有就是，分布式数据库是可以考虑进去的，但是我也觉得多种类型数据库倒真没有什么必要……   回复  引用  查看    

#160楼 2008-03-20 22:43 预备役中尉      

渐渐离开WEB了.还是关注中.   回复  引用  查看    

#161楼 2008-03-20 23:45 光影传说      

@Jeffrey Zhao
多库分布是必须要考虑进去的，如果没有多库，则没有必要搞的那么复杂。最终的难题，我估计应该会在多库分布这个核心点上面。   回复  引用  查看    

#162楼 2008-03-21 00:03 坏人      

多数据库支持完全没必要做,一开始选好要用什么库就好了.

分库通常也没意义,做好数据库的负载就好,再把缓存做好就足够.   回复  引用  查看    

#163楼 2008-03-21 01:15 RicCC      

这种分层只是形式，接口/类/代码量会带来无谓的复杂性和工作量，并不见得维护性能得到改善
大型网站程序这样做的应当比较少，性能(包括缓存方案)、伸缩性是两大关键，把这两项设计好就OK，其它用最快捷的方式实现，中间每引入一个框架可能意味着开发过程以及维护阶段要面临很多问题

两个想法
1. dotext好像把文章存数据库了，这样带来的性能瓶颈太大，可以考虑文章只存为文件，用lucence做搜索
2. blog系统比较好实现线性伸缩，可以在这方面多考虑   回复  引用  查看    

#164楼 2008-03-21 01:35 一抹微蓝      

进来学习，现在还插不上话。
希望有朋友可以介绍一下多库分布   回复  引用  查看    

#165楼 2008-03-21 08:24 小哈      

關注
重構是一項大的工程
需求會一直變動,技術也在不斷翻新,或者在目前的專案上去精簡代碼,實現可擴展性的新需求   回复  引用  查看    

#166楼 2008-03-21 08:53 yangaska[未注册用户]

背景音乐不错挺好听   回复  引用    

#167楼 2008-03-21 09:11 appleseeker      

@dudu
可以将文章以xml形式存放，然后用xslt,xsd对xml进行约束、修饰、展现。   回复  引用  查看    

#168楼 2008-03-21 09:42 Anytao      

如果是大刀阔斧的重构，考虑多数据库支持还是必要的，要不然以后的维护会有更多麻烦。
整体的架构还是很经典的，在传统三层架构上，隔离出服务层，我认为基于以后的需求扩展考虑也是应该，WCF绝对是不错的选择。不过正如老赵所说，增加通信成本是无疑的。   回复  引用  查看    

#169楼 2008-03-21 09:54 aysun168[未注册用户]

你这歌曲很好听!   回复  引用    

#170楼 2008-03-21 10:13 JackMa      

开发团队你们辛苦了！致敬！   回复  引用  查看    

#171楼 2008-03-21 10:14 none11[未注册用户]

简单   回复  引用    

#172楼 2008-03-21 10:16 KidYang      

如果有可能，觉得还是重写好一点   回复  引用  查看    

#173楼 2008-03-21 10:24 Tony Zhou      

某些精妙的实现可以考虑部分开源，我喜欢service layer   回复  引用  查看    

#174楼 2008-03-21 11:15 Tristan(Guozhijian)      

业务外观层有没有必要？
难道所有业务都需要外观？

业务层也要全部抽象出Interface吗？有什么用？这点我比较奇怪   回复  引用  查看    

#175楼 2008-03-21 11:17 Mainz      

复杂了点，有点过度设计

针对用户体验和性能多设计一下吧，博客园业务倒不是那么复杂的！   回复  引用  查看    

#176楼 2008-03-21 12:24 Ryan Yu      

向开发团队致敬   回复  引用  查看    

#177楼 2008-03-21 12:56 deerchao      

建议别搞这么重量级,轻一点,敏捷一点..   回复  引用  查看    

#178楼 2008-03-21 13:07 早班火车      

感觉鲜果的模式还不错，有自己的一套digg机制，
好文章看的人多顶的人也多，自然而然就区分出精华了。
前期的需求分析真的重要。
可扩展性，伸缩性，性能，用户体验很多都需要考虑的很清楚。
博客园开发团队辛苦了~一如既往的支持博客园~
  回复  引用  查看    

#179楼 2008-03-21 14:01 test0012008[未注册用户]

--引用--------------------------------------------------
lxinxuan: 我们的网站从04年存在，经历了无数人的蹂躏，不管数据库和代码都是乱的一塌糊涂。。。号称最近要升级到2.0（目前是1.1），难啊。
--------------------------------------------------------

比你惨！

我的一个OA系统是一个大工厂集团03年上线的，.net 1.1的，历经公司N代程序程序员的修改，里面的功能早就脱离的 OA系统的范畴，系统没有分层，没有架构，所有的逻辑杂到一起，就着个烂系统，支撑这一个上百千亿营业额的工厂，，
目前就我一个人维护，，最近猛然听说要重写，但要保持原有的数据和所有功能，，，我的娘，我一听头就大，浑身冒汗！   回复  引用    

#180楼 2008-03-21 14:29 awen177[未注册用户]

强贴留名，向各位高手学习咯！   回复  引用    

#181楼 2008-03-21 14:32 小妮爹      

可以将文章以xml形式存放，然后用xslt,xsd对xml进行约束、修饰、展现。
这样seo效果不好。
多数据库设计是愚蠢的。整个程序不支持几个数据库就好像不是程序是的？博客园一共的贴子有六七十万没？贴子内容存在文件内，标题啥地存在DB里，也就能用个百八十M。在把table按年分一下啥地,数据库这块就搞定了。
存成文件是王道。文章内容千万不要放在数据库里，太没用了。shtml也狠灵活

什么表现层接口啥地简直简直不可理解。web这玩意需求就是时时在变，时时在改。在说博客园能有啥程序呀。

努力地把程序整简单，功能也整简单。这样重构一回还值得。   回复  引用  查看    

#182楼 2008-03-21 16:54 imxjb[未注册用户]

重构的路比较艰难，如何保障重构后的使用习惯的新适应，是最大的问题   回复  引用    

#183楼 2008-03-21 16:54 Jeffrey Zhao      

--引用--------------------------------------------------
dudu: @Jeffrey Zhao
Service Layer相当于业务外观层。
--------------------------------------------------------
和Business Layer相比作用是什么呢？   回复  引用  查看    

#184楼 2008-03-21 18:21 Jonny Yu      

dudu,

博客园的程序有多少行啊？

其实一直觉得博客园的系统从功能，性能和稳定性来说都是很令人满意的。
看到这个整体重构计划确实有点吃惊。

只看这张图不知道具体要解决哪些问题，大家讨论没有中心。而且最后还都会落到一句话：看实际需要了。
所以如果方便公开的话，能不能讲讲在这张设计图背后，开发团队实际碰到了哪些问题呢？相信园子里面架构师、高级程序员应该都不少，讨论具体的问题的时候大家肯定会讨论出好主意的。

  回复  引用  查看    

#185楼 2008-03-21 19:27 路人A[未注册用户]

好强大的气势..   回复  引用    

#186楼 2008-03-21 20:55 怪怪      

天呀...   回复  引用  查看    

#187楼 2008-03-21 22:26 乌生鱼汤      

oracle的东西可以装的吗？   回复  引用  查看    

#188楼 2008-03-22 02:53 somesongs      

--引用--------------------------------------------------
RicCC: 这种分层只是形式，接口/类/代码量会带来无谓的复杂性和工作量，并不见得维护性能得到改善
1. dotext好像把文章存数据库了，这样带来的性能瓶颈太大，可以考虑文章只存为文件，用lucence做搜索
2. blog系统比较好实现线性伸缩，可以在这方面多考虑
--------------------------------------------------------

Lucene做索引倒不是那么必要吧，性能和索引更新是个麻烦。用Google足矣。
  回复  引用  查看    

#189楼 2008-03-22 03:00 somesongs      

我觉得将文章内容是不是存成文件，还是需要做实验和测试的，不见得存成文件，在并发访问中的效率就比数据库高。

况且文件还是数据库，Seo可只管Link的形式。   回复  引用  查看    

#190楼 2008-03-22 10:14 啊不才      

@三磊
正如三磊说的，希望能公开整个过程，让大家从中学习到最宝贵的知识，这应该比给大家提供一个更好的平台更加实用一些。   回复  引用  查看    

#191楼 2008-03-22 11:25 极地银狐.NET      

还没有明白?这样的重构并不能解决问题.   回复  引用  查看    

#192楼 2008-03-22 17:53 GoGoSonny      

数据库写死好了，注意性能。   回复  引用  查看    

#193楼 2008-03-23 18:46 森要[未注册用户]

就一个博客系统能有多复杂？我觉得搞这么大一个框架反而是对资源的浪费，
根本就没有必要考虑分这么多层搞这么多接口，还用多数据库，难道今天用MSSQL，明天就要换ORACLE，后天又再换？我参与过十几个大网站项目，从来没听说过有必要换数据库的。我觉得应该重点在访问速度和稳定性以及用户上，多考虑一下分布式。
个人认为，多层结构，各种复杂的框架，更多的考虑是开发人员的体验，怎么样开发快，怎么样适应业务改动，其次才会考虑应用方的感受，软件商只考虑开发效率，同一套系统尽可能卖给更多的客户，适应更多客户的需求，追求最大的经济效益。而客户最需要的是什么？稳定，高速，经济，而不会太在意用的什么语言什么框架。   回复  引用    

#194楼 2008-03-24 11:56 吉日嘎拉[未注册用户]

这个框架，我基本上都做出来了，比这个更多一些，
还有winform 功能部分。   回复  引用    

#195楼 2008-03-25 09:50 Ticky      

看到这么这些复杂的架构,我就感到兴奋,哈哈哈.
希望可从中分享经验   回复  引用  查看    

#196楼[楼主] 2008-03-25 18:28 dudu      

非常感谢大家的建议!
我们会根据大家的建议改进架构设计。   回复  引用  查看    

#197楼 2008-03-25 19:27 吉日嘎拉[未注册用户]

楼主若有兴趣，可以加我msn，我这里的一些成果，愿意与楼主分享
  回复  引用    

#198楼 2008-03-29 21:14 糊涂小猪      

看这架构不错啊。DUDU要是能把开发的整个流程写下来那就更好了，大家共同学习啊。   回复  引用  查看    

#199楼 2008-04-07 12:45 javaer      

呵呵.
初次来这.
支持下博主.   回复  引用  查看    

#200楼 2008-04-21 14:12 天好蓝-崇崇      

@awen177
可怜~~~~~~~~~~~

重写还好说,技术对你应该不是问题.

问题是重写,而数据库还是老样子不动,确实很头大........


深表同情啊......

干脆把数据模型也重构之,跟主观讨论下.
长疼不如短痛...........   回复  引用  查看    

• 我的参与
• 我的新闻
• 最新评论
• 我的标签

Powered by:
博客园
Copyright © dudu