问题描述
web开发不是特别多但是也不算是新手了觉得一个web项目的架构web--直接webformdalbllcommonmodel差不多这样就够了对于分层架构没有异议但是对于web表示层现在貌似mvc大行其道说实在的我觉得除了那些个多余的配置我没有看到什么特别的好处还有就是orm的框架用起来也不觉得多么方便啊直接存储过程ado调用数据库有什么不好么到时候数据库迁移换数据库或者是同一个数据库换其他开发语言也很方便存储过程不用重复开发了大家都什么意见呢对于webform我个人觉得还是以干净的html加少量服务器控件为主开发起来配合jquery也非常简洁高效啊
解决方案
解决方案二:
只是个人比较喜欢用MVC。
解决方案三:
你首先要了解一个框架的意义,他的存在价值不是外行人所能了解的MVC字面上的意思就是模型、视图(显示模板)、控制器(控制显示哪个模板)一个模型可以用多个显示模板进行显示(比如说文字列图,图片列表,大图列表等),通过控制器来控制显示哪个模板,这个MVC的核心内容最常见的应用
解决方案四:
引用1楼Jelly1989的回复:
只是个人比较喜欢用MVC。
可以说下原因么?难道是我太保守技术陈旧?它给你带来了什么方便或者好处?
解决方案五:
引用2楼liuchaolin的回复:
你首先要了解一个框架的意义,他的存在价值不是外行人所能了解的MVC字面上的意思就是模型、视图(显示模板)、控制器(控制显示哪个模板)一个模型可以用多个显示模板进行显示(比如说文字列图,图片列表,大图列表等),通过控制器来控制显示哪个模板,这个MVC的核心内容最常见的应用
不是说了么我也不是新手了mvcmvp甚至mvvm我都了解也开发过只是觉得mvc没有真的给我带来实惠呵呵
解决方案六:
引用4楼lhx527099095的回复:
Quote: 引用2楼liuchaolin的回复:
你首先要了解一个框架的意义,他的存在价值不是外行人所能了解的MVC字面上的意思就是模型、视图(显示模板)、控制器(控制显示哪个模板)一个模型可以用多个显示模板进行显示(比如说文字列图,图片列表,大图列表等),通过控制器来控制显示哪个模板,这个MVC的核心内容最常见的应用不是说了么我也不是新手了mvcmvp甚至mvvm我都了解也开发过只是觉得mvc没有真的给我带来实惠呵呵
当你的技术达到一个位置时自然会明白,MVC不是指vs里的MVC,而只一种概念,他可以用任何方式来实现,可以与工厂模式共存,也可以是PHP和Java的,这就是所谓的不要为了框架而框架的意思
解决方案七:
引用5楼liuchaolin的回复:
Quote: 引用4楼lhx527099095的回复:
Quote: 引用2楼liuchaolin的回复:
你首先要了解一个框架的意义,他的存在价值不是外行人所能了解的MVC字面上的意思就是模型、视图(显示模板)、控制器(控制显示哪个模板)一个模型可以用多个显示模板进行显示(比如说文字列图,图片列表,大图列表等),通过控制器来控制显示哪个模板,这个MVC的核心内容最常见的应用不是说了么我也不是新手了mvcmvp甚至mvvm我都了解也开发过只是觉得mvc没有真的给我带来实惠呵呵
当你的技术达到一个位置时自然会明白,MVC不是指vs里的MVC,而只一种概念,他可以用任何方式来实现,可以与工厂模式共存,也可以是PHP和Java的,这就是所谓的不要为了框架而框架的意思
好吧原来是我low了其实我就是想问问它带来的好处以及我们在构建项目时候如何选择webform或者mvc的项目进行开发当然原来我也写过javacodemvc的概念我是在java里面了解到的那好比如果现在你自己写项目会选择普通的webform还是mvc项目来开发表现层呢?
解决方案八:
如果没有特定要求(你们老大或客户的要求),那当然是自由发挥,哪个写得快且效率当然就怎么写了,我们抛开vs里mvc的模型,不是还有动软代码生成器之类的工具吗,只要能以最快的方法实现才是你们老板所需要的
解决方案九:
MVC是一个事实标准的web后端架构,它解决了将url请求、web前端页面和后端逻辑分开的问题。它是解决特定问题的特定框架而已。如果你认为它可以让你写程序更不动脑筋,或者平添了很多优势,那是你被某些无良的技术文章误导和忽悠了。
解决方案十:
引用7楼liuchaolin的回复:
如果没有特定要求(你们老大或客户的要求),那当然是自由发挥,哪个写得快且效率当然就怎么写了,我们抛开vs里mvc的模型,不是还有动软代码生成器之类的工具吗,只要能以最快的方法实现才是你们老板所需要的
恩恩这才是高见其实客户不关心具体技术细节只看最后网站招个好点的前端美工才是王道。。。。。
解决方案十一:
我说了,因为MVC是一种事实上标准的架构,所以一个用asp.netmvc开发的网站,可以很容易用struts或者ror改写,反之亦然。你用asp.netwebforms的话,你用jsp改写下试试?
解决方案十二:
引用8楼caozhy的回复:
MVC是一个事实标准的web后端架构,它解决了将url请求、web前端页面和后端逻辑分开的问题。它是解决特定问题的特定框架而已。如果你认为它可以让你写程序更不动脑筋,或者平添了很多优势,那是你被某些无良的技术文章误导和忽悠了。
恩恩只是觉得大家都在大谈mvc其实个人没有发现它能够带来的特别大的优势也许是我的项目没有它发挥的优势所以才感觉webform处理得当一样好用其实我还想请教下是不是mvc对于自动化测试比较好如果用传统的webform如何搭建良好的unittest的项目框架呢?unittest的覆盖是不是就到dal->bll这层了不过说实在的webui展示层的测试大部分还是靠人工。。。。。
解决方案十三:
引用10楼caozhy的回复:
我说了,因为MVC是一种事实上标准的架构,所以一个用asp.netmvc开发的网站,可以很容易用struts或者ror改写,反之亦然。你用asp.netwebforms的话,你用jsp改写下试试?
哎呀呀我觉得你这句就是我想要得到的结果了知道了谢过~~~~~
解决方案十四:
ui测试本来就靠人工(或者说模拟人工)VS2010开始,微软增加了一个基于代码的UI测试(CodedUITest)的组件,允许你手工操作界面,并且录制成脚本,以后用脚本模拟操作它实现UI自动测试。http://blogs.microsoft.co.il/eranruso/2010/03/27/visual-studio-2010-coded-ui-test-user-guide-create-a-simple-coded-ui-test/
解决方案十五:
引用13楼caozhy的回复:
ui测试本来就靠人工(或者说模拟人工)VS2010开始,微软增加了一个基于代码的UI测试(CodedUITest)的组件,允许你手工操作界面,并且录制成脚本,以后用脚本模拟操作它实现UI自动测试。http://blogs.microsoft.co.il/eranruso/2010/03/27/visual-studio-2010-coded-ui-test-user-guide-create-a-simple-coded-ui-test/
我觉得还是模拟人工比较靠谱。不过浪费时间你要写很多的测试代码。即便你封装的多么好,一旦数据出现意外依然测不准。
解决方案:
解决方案:
webform把本来很简单的web开发变得复杂,说句不好听的,谁用谁吃亏。况且,MVC跟Webform没有什么关系。MVC是一个概念,不是具体框架或工具。
解决方案:
引用16楼ktei2008的回复:
webform把本来很简单的web开发变得复杂,说句不好听的,谁用谁吃亏。况且,MVC跟Webform没有什么关系。MVC是一个概念,不是具体框架或工具。
那原来你都用什么开发呢?纯htmlajax调用后台处理?那样有点锻炼前端js功力的意思啊
解决方案:
引用17楼lhx527099095的回复:
那原来你都用什么开发呢?纯htmlajax调用后台处理?那样有点锻炼前端js功力的意思啊
首先大行其道的并不一定就是好的,更不一定就是你需要的。比如说我从2005年第一次接触webform,我就知道它不是我要的,我要的是html+js,虽然那时候的“ajax”实现手段与现在不同。另外asp.netmvc是一个框架实现,并不能指代mvc这个概念,mvc的效应也不是仅仅止步于mvc的概念。就好像人类学会了使用金属,不是只有简单的字面上的意义。看起来楼主有点抗拒js,这是很正常的,所谓术业有专攻,只做一件事效率应该是比较高的,而且是舒心的。逻辑与UI分离,很可能起到同样的作用,分而治之很可能思路没那么混乱,干起活来更舒心了。当然这也只是可能,对于有些人有些情况来说也可能觉得更麻烦了。不同的人感觉不同吧。如果你要说换数据库,这点应该反而是ORM的优势。比如数据库不一定支持存储过程,数据库不一定非得是关系数据库,数据库一定支持SQL语句,SQL语句也不一定能兼容。一般的ORM都能轻松的永久解决这些问题,当然也有一些ORM没有这功能。如果要换开发语言,一般来说数据库这一块真不是什么大事,除非你的程序就是个企业管理器的扩展。如果做web开发的连js都抗拒的话,还能换个什么省心的语言。楼主提到少量服务器控件+jquery,说明已经开始排斥webform了。如果有需要的话,可以考虑把这些都改成客户端控件,使用ajax与服务器交互,这时候就可以学习与了解一些前端UI框架(不是jquery这种类库哦)。比如说传统的UI操作可能是这样的$(XXX).html("<ahref='"+href+"'>"+title+"</a>");而基于web视图的UI操作可能是这样的,注意这里改变是的所有与XXX有关的界面内容。XXX.Set({href:href,title:title});如果体会不到某种开发手段的好处的话,说明至少现阶段不适合使用该种开发手段。
解决方案:
我是过来学习的
解决方案:
我是新手,我只是过来膜拜各位大神
解决方案:
当你对非常相似的UI编程50遍的时候,你copy了一大堆UI代码,理由只是“他们有一些差别啊,所以只能垃圾copy!”这个,那么这时候就体现出UI层进行再进行分层的好处了。因为将UI中凡是“数据参数”的部分单独抽象出来,你就可以写“从M到V的自动化映射代码”,也就是说可以大量地使用模式匹配来自动化生成代码。可能是因为asp.netmvc比较垃圾,没有强调“非编程的程序设计模式”,所以让这种分层的好处化作乌有。只要是你不懂“少写代码才是编程的根本”,你以为什么都是copy代码然后修改它,你就不能理解大多数分层模式。
解决方案:
比如说,复杂的新浪新闻页面跟同样复杂的凤凰新闻页面有多大区别?差别很大吧?但是它们的Model层完全可以是一样的!而从Model到View以及处理各种交互响应事件,完全可以用模板自动化、标准化地生成和发布(不需要手工编码),这就是MVC要告诉你的。
解决方案:
sp1234说的对,少写代码才是编程的根本。层次功能越简单(单纯),越容易做到机器可读,越容易实现自动化编码或者根本就不用代码(只需要基本模块)。才可能做到应用上,只为个性化需求的编码代码。
解决方案:
引用11楼lhx527099095的回复:
不过说实在的webui展示层的测试大部分还是靠人工。。。。。
正因为采用MVC设计模式,UI层就不需要人工测试了,MVC的UI可不是靠人工编写代码的,而是由视图控制器渲染的,vs提供的脚本录制的测试方式实际上对拥有自动化测试能力的开发组织没有多大帮助
解决方案:
你把webform中的page也当作是一层控制器来使用,同样可以实现MVC的设计模式,通过路由约定就可以实现不同的视图模型和业务模型的组合,生成所需的各个UI
解决方案:
Model并不一定只涉及业务数据,实际上UI控件所需要的、属于可以灵活调整的数据属性,都可以放到Model中。进一步地,各种数据处理行为也放到Model中。结果,你的UI中混合的大多数代码,都可以放到Model中。剩下的代码(剩下的View层)基本上不需要手工编程,而是需要美工人员进行数据绑定!
解决方案:
对于一个具体的工具有什么问题,我们可以具体讨论它的问题。例如我就肯定不使用asp.netmvc。但是不要扩大到没有边际的方面,不要否认原理和模式的重要性。
解决方案:
该回复于2014-10-11 20:33:18被版主删除
解决方案:
公司需要,你就得学。。
解决方案:
表太理想化了。你用MVC,可能是因为老板需要或者客户需要,你可能无法体会到它的理论优点;而你不用MVC,也可能是项目日程需要,开发人员技术门槛不够等等因素,你同样体会不到不用的缺点;所以,该干啥干啥,没必要纠结。程序员就是一般苦逼的人
解决方案:
mvc的model跟“三层”的model不是一个概念,要注意!三层中的model,用来跨三层而进行通讯。而mvc中的model,集中在UI层内部更底层的数据建模需求,因此mvc的model包括了一部分界面组件才需要的属性。我从来没有听说过什么用户需要mvc。基本上所谓“老板需要mvc”也是出现在很小的公司里,因为程序员基本上都是实习生,所以只能搞点简单概念进行僵化模仿,对他们不能要求什么设计知识。事实上老板如果花好5年时间还在只会强调“mvc”呢,我觉得这其实是一种讽刺(当非常耐心地给他们介绍mvc的时候,这个老板其实可能心里是瞧不起程序员的),这个开发组大概只能如此了。因此作为一个程序员,如果觉得“死猪不怕开水烫,俺就这个水平,你说啥就是啥,反正我无所谓学习”,那么小公司的老板就该偷偷哭去了(尽管他表面上还在夸这样的程序员)。
解决方案:
这其实是最简单的模式,懒得讨论。我们只是介绍一下概念而已。我见过一些公司花了较多的钱聘请的几个程序员整天纠结于这类东西吵来吵去,而整个公司开发层次很低很低,一切都是“分解一下界面,然后各自开发”的小作坊式的。这其实就是因为老板只会弄最简单的简单mvc模式分层,而不会直截了当地从更高开发效率的组件设计层次的设计入手。
解决方案:
什么时候、什么人才能有模式研究的需求?如果拿建筑材料来打比方,那么就是那些设计和制造各种建筑预制件、装置和通用仪器等等的人,才会有越来越多这方面需求。软件公司也是这样。做组件设计的人,不会动不动推倒重来的。因为它们会分层、会灵活地将层次衔接部分进行修改和反向设计。因此才需要研究模式。如果没有养成逐步研发几十个组件进行复用的设计的概念,而是像小作坊一样只会“自顶向下”地去分解界面然后就等待着其“各自开发”,那么其实这种人就和自然会觉得分层设计没有必要。(这些人当遇到“推倒重来”几遍之后感觉“受不了了”,就开始考虑换一个公司去工作了,把工作扔给后续接手人员了)所以看一个结论,先看人。
解决方案:
引用33楼sp1234的回复:
什么时候、什么人才能有模式研究的需求?如果拿建筑材料来打比方,那么就是那些设计和制造各种建筑预制件、装置和通用仪器等等的人,才会有越来越多这方面需求。软件公司也是这样。做组件设计的人,不会动不动推倒重来的。因为它们会分层、会灵活地将层次衔接部分进行修改和反向设计。因此才需要研究模式。如果没有养成逐步研发几十个组件进行复用的设计的概念,而是像小作坊一样只会“自顶向下”地去分解界面然后就等待着其“各自开发”,那么其实这种人就和自然会觉得分层设计没有必要。(这些人当遇到“推倒重来”几遍之后感觉“受不了了”,就开始考虑换一个公司去工作了,把工作扔给后续接手人员了)所以看一个结论,先看人。
解决方案:
引用18楼sbwwkmyd的回复:
Quote: 引用17楼lhx527099095的回复:
那原来你都用什么开发呢?纯htmlajax调用后台处理?那样有点锻炼前端js功力的意思啊首先大行其道的并不一定就是好的,更不一定就是你需要的。比如说我从2005年第一次接触webform,我就知道它不是我要的,我要的是html+js,虽然那时候的“ajax”实现手段与现在不同。另外asp.netmvc是一个框架实现,并不能指代mvc这个概念,mvc的效应也不是仅仅止步于mvc的概念。就好像人类学会了使用金属,不是只有简单的字面上的意义。看起来楼主有点抗拒js,这是很正常的,所谓术业有专攻,只做一件事效率应该是比较高的,而且是舒心的。逻辑与UI分离,很可能起到同样的作用,分而治之很可能思路没那么混乱,干起活来更舒心了。当然这也只是可能,对于有些人有些情况来说也可能觉得更麻烦了。不同的人感觉不同吧。如果你要说换数据库,这点应该反而是ORM的优势。比如数据库不一定支持存储过程,数据库不一定非得是关系数据库,数据库一定支持SQL语句,SQL语句也不一定能兼容。一般的ORM都能轻松的永久解决这些问题,当然也有一些ORM没有这功能。如果要换开发语言,一般来说数据库这一块真不是什么大事,除非你的程序就是个企业管理器的扩展。如果做web开发的连js都抗拒的话,还能换个什么省心的语言。楼主提到少量服务器控件+jquery,说明已经开始排斥webform了。如果有需要的话,可以考虑把这些都改成客户端控件,使用ajax与服务器交互,这时候就可以学习与了解一些前端UI框架(不是jquery这种类库哦)。比如说传统的UI操作可能是这样的$(XXX).html("<ahref='"+href+"'>"+title+"</a>");而基于web视图的UI操作可能是这样的,注意这里改变是的所有与XXX有关的界面内容。XXX.Set({href:href,title:title});如果体会不到某种开发手段的好处的话,说明至少现阶段不适合使用该种开发手段。
感谢您热心的回答其实不是特别纠结js而且我也说了个人也比较喜欢纯净的html+js问题在说的明白点如果现在您要自己搞个web项目您会采用什么样的架构呢?要考虑今后可能会从微软系的架构切换到java系的架构请问您有什么建议呢要考虑哪些问题呢?
解决方案:
以前刚开始用mvc的时候也觉得很烦,根本没有必要,现在用着觉得还挺带感的,不用的话总是觉得无从下手首先mvc的存在是为了让术业专攻,后台的做后台的M,前台的专注与前端的v,然后让对这软件内容领域熟悉的人来做C层实现对接这样可以提高效率和质量比如我做个计算器,实现加计算后台做个函数前端设置结果的显示位置,由controller来获得前端的两个加数,然后调用后台函数,算出结果再给前端显示像这样,前端可以找个精通html和js,css的人来做个好看的页面,炫酷的效果,他只需要懂html和js,css就行了后台就找个算法高手做,他无需知道任何一点关于html和js,css的知识不过现在一个人做的时候用mvc也挺好的,实现了代码的分离,哪个部分出现问题,可以直接去那个地方找,便于维护虽然程序的所有代码都可以用1个页面实现,但这样不就显得繁琐?所以我们一般做程序都用多个页面写代码个人觉得mvc只是把我们想要分开写的代码,通用地官方地分成了mvc3个大类别.其实我做web的时候虽然习惯用mvc3但是v层我一般也分3个类别html,css,js这样布局直接html,样式调用css文件,再在js的分类文件夹中控制html中的元素行为这样看起来比较清爽,也便于维护我一直想直接在html中用各种<div>标签+id分割各个模块,然后在css中根据id分别设置各个div元素的大小位置什么的属性最后在js文件中设置各个div的行为这样用起来会让我整个人都觉得清爽但是太不现实了,像input,img,a什么标签用<div>+css+js实现起来超麻烦大部分标签其实都整合封装了功能,我们使用时候直接一个标签了事,非常便捷,因为是类似封装的,无法完全,清晰明了地控制到最底层,总感觉十分别扭,不够清爽果然分离和便捷两件事就是矛与盾,无法绝对倾向哪个,现在的html用法大概就是中和了2个方面所得出来的一种用法吧,不上不下地orm还是比较便利的,省了你大量代码的编写,但是不够灵活,有很多冗余,考虑效率或者用不习惯还是自己写好了至于ado和存储过程ado是为了便于对数据库操作的封装,比如你换了数据库编程语言没变,那么ado的代码大多不需要改变,方便你换数据库如果数据库不便,而是换开发语言,那么存储过程比较方便,如果换语言的话,你不是.net开发的话还怎么用ado
解决方案:
引用23楼sbwwkmyd的回复:
sp1234说的对,少写代码才是编程的根本。层次功能越简单(单纯),越容易做到机器可读,越容易实现自动化编码或者根本就不用代码(只需要基本模块)。才可能做到应用上,只为个性化需求的编码代码。
那设计模式不是走的反路吗。
解决方案:
引用35楼lhx527099095的回复:
感谢您热心的回答其实不是特别纠结js而且我也说了个人也比较喜欢纯净的html+js问题在说的明白点如果现在您要自己搞个web项目您会采用什么样的架构呢?要考虑今后可能会从微软系的架构切换到java系的架构请问您有什么建议呢要考虑哪些问题呢?
服务器端仅仅定义UI视图class,并自动生成客户端调用数据接口(一般来说就是把class转换成JSON)。客户端根据约定的数据接口规则自动使用ajax获取数据并根据UI模板生成UI界面。这样子写一个普通的展示页面只需要做两件事,一是服务器端定义UI视图class并给数据赋值,二是UI模板数据绑定(如果你的UI模板规则简单的话完全可以交给美工做),其他的工作都可以自动化处理。不管服务器端换什么语言,都只需要提供同样的数据接口即可。而客户端仅仅与数据接口相关,无需任何改动。引用37楼ZuoQingYi的回复:
那设计模式不是走的反路吗。
我认为设计模式是给不想事的初学使用的一个方法论。
解决方案:
UI视图并不是非要一个页面匹配一个,比如你可以建立一个全局UI视图,所有页面都只用它。当有新的数据需求的时候,就给它添加一个新属性。这样做有一个问题,就是很可能需要为新属性的命名而烦恼。
解决方案:
引用35楼lhx527099095的回复:
Quote: 引用18楼sbwwkmyd的回复:
Quote: 引用17楼lhx527099095的回复:
那原来你都用什么开发呢?纯htmlajax调用后台处理?那样有点锻炼前端js功力的意思啊首先大行其道的并不一定就是好的,更不一定就是你需要的。比如说我从2005年第一次接触webform,我就知道它不是我要的,我要的是html+js,虽然那时候的“ajax”实现手段与现在不同。另外asp.netmvc是一个框架实现,并不能指代mvc这个概念,mvc的效应也不是仅仅止步于mvc的概念。就好像人类学会了使用金属,不是只有简单的字面上的意义。看起来楼主有点抗拒js,这是很正常的,所谓术业有专攻,只做一件事效率应该是比较高的,而且是舒心的。逻辑与UI分离,很可能起到同样的作用,分而治之很可能思路没那么混乱,干起活来更舒心了。当然这也只是可能,对于有些人有些情况来说也可能觉得更麻烦了。不同的人感觉不同吧。如果你要说换数据库,这点应该反而是ORM的优势。比如数据库不一定支持存储过程,数据库不一定非得是关系数据库,数据库一定支持SQL语句,SQL语句也不一定能兼容。一般的ORM都能轻松的永久解决这些问题,当然也有一些ORM没有这功能。如果要换开发语言,一般来说数据库这一块真不是什么大事,除非你的程序就是个企业管理器的扩展。如果做web开发的连js都抗拒的话,还能换个什么省心的语言。楼主提到少量服务器控件+jquery,说明已经开始排斥webform了。如果有需要的话,可以考虑把这些都改成客户端控件,使用ajax与服务器交互,这时候就可以学习与了解一些前端UI框架(不是jquery这种类库哦)。比如说传统的UI操作可能是这样的$(XXX).html("<ahref='"+href+"'>"+title+"</a>");而基于web视图的UI操作可能是这样的,注意这里改变是的所有与XXX有关的界面内容。XXX.Set({href:href,title:title});如果体会不到某种开发手段的好处的话,说明至少现阶段不适合使用该种开发手段。
感谢您热心的回答其实不是特别纠结js而且我也说了个人也比较喜欢纯净的html+js问题在说的明白点如果现在您要自己搞个web项目您会采用什么样的架构呢?要考虑今后可能会从微软系的架构切换到java系的架构请问您有什么建议呢要考虑哪些问题呢?
如果我是你,我只会先确定我用哪一种语言,比如Java,C#,PHP等等,除此以外的我不考虑。我不会从具体框架开始,我甚至不会假设我做的是web程序或webAPI或桌面程序。我会先从逻辑层下手,用TDD(测试驱动)的方式把逻辑层建立起来。当然了,逻辑层是需要依靠其他低层的,但是没关系,在UnitTest中mock就可以了。逻辑层跑通了以后,我再来考虑其他的。Alwaysleaveyourselfinaopenposition.Alwaysdelaymakingdecisions.
解决方案:
所有框架都不是绝对的,不要转牛角尖.
解决方案:
此帖中的讨论很激烈,很不错,推荐一下,让更多的人参与进来
解决方案:
因为自己有前端的功底吧,我觉得mvc用起来非常方便,至少个人这样应为,而且很好的配合自己写jquery插件
解决方案:
引用37楼ZuoQingYi的回复:
Quote: 引用23楼sbwwkmyd的回复:
sp1234说的对,少写代码才是编程的根本。层次功能越简单(单纯),越容易做到机器可读,越容易实现自动化编码或者根本就不用代码(只需要基本模块)。才可能做到应用上,只为个性化需求的编码代码。那设计模式不是走的反路吗。
扯蛋么,设计模式的目的也是提高代码的复用性.可复用的东西多了要写的东西就少了.如果你应用某个模式并没有使代码减少,那你就应该考虑这是是不是用对了.
解决方案:
引用33楼sp1234的回复:
什么时候、什么人才能有模式研究的需求?如果拿建筑材料来打比方,那么就是那些设计和制造各种建筑预制件、装置和通用仪器等等的人,才会有越来越多这方面需求。软件公司也是这样。做组件设计的人,不会动不动推倒重来的。因为它们会分层、会灵活地将层次衔接部分进行修改和反向设计。因此才需要研究模式。如果没有养成逐步研发几十个组件进行复用的设计的概念,而是像小作坊一样只会“自顶向下”地去分解界面然后就等待着其“各自开发”,那么其实这种人就和自然会觉得分层设计没有必要。(这些人当遇到“推倒重来”几遍之后感觉“受不了了”,就开始考虑换一个公司去工作了,把工作扔给后续接手人员了)所以看一个结论,先看人。
很透彻啊
解决方案:
顶起啊,个人还是觉得哪个好用用哪个,最主要是要考虑扩展性
解决方案:
mvc虽然用了才不久,了解也不够深入,但是那种多主题,多模板的快捷更换还是倍喜欢
解决方案:
mvc是设计思想。。。
解决方案:
webform是目前为止最好、最高效的网页程序开发工具,而之所以webform不受欢迎,原因主要是有2点:1:webform太难!!webform的工作运行原理一个程序员至少需要认真学习和实践使用2、3年时间才能基本上了解,要游刃有余的试用甚至需要更长事件。2:Webform没有做到极致,甚至说有点虎头蛇尾,框架前期设计理念上很好,但到后面,忽略了客户端功能开发,很多东西没有做到极致。
解决方案:
学习了