问题描述
做一个asp.net站点。现在开发方式是什么？1.有几个是直接拖拉数据组件sqldatasource，然后直接操作数据库，有几个是直接FormViewGridView向导直接快速开发模式来做一个项目的；有几个是都把类库放在App_Code文件夹下的开发方式，有几个是用三层结构来开发的。注：后面两者，你们开发的时候，哪个情况比较多？2.asp.net站点前台你们开发时是A。美工设计好图片，程序员自己切割图片做成html，再做成aspx;B.美工设计好图片，并作成html，程序员根据html做成aspx;3.asp.net站点后面页面开发时A。美工设计好页面，程序员切割图片做成html,再做成aspx;B.美工设计好图片，并作成html，程序员根据html做成aspx;C.全部归程序员管4.程序员的你具备哪种经常主用到的布局能力A.CSS+DIV;B.Table布局C.当然布局经常是A+B合起来的（这个不讨论）5.性能优化策略-------算了这个有时间另开一贴进行讨论6.安全开发策略-------算了这个有时间另开一贴进行讨论7.具备服务器配置条件的，你如何配置安全的站点-------算了这个有时间另开一贴进行讨论
解决方案
解决方案二：
第一点没看懂第二、三点没有html的过程，美工出效果图，自己看着做，局部图片也懒得切割，让美工作。第四点：DIV和table都在用第五点：原则是不要把自己做惨了，但同时又能够用户接受。第六、七点：其它不说，记住找一个带硬件防火墙，能防ARP的空间部署。
解决方案三：
mark
解决方案四：
12b3b4都了解
解决方案五：
1三层开发2，3美工设计好图片，再写CSS和DIV，生成模板，根据模板写页面。4CSS，DIV，table都用;
解决方案六：
1不理解2B3B4C
解决方案七：
引用4楼wuyq11的回复:
1三层开发2，3美工设计好图片，再写CSS和DIV，生成模板，根据模板写页面。4CSS，DIV，table都用;
我也基本这样
解决方案八：
大凡真正的设计师设计产品，都是先考虑好需要的效果，然后再考虑如何制作产品的各个环节。正因为习惯于这种异于常人的思维方式，所以具有最强的接受能力，总是不论什么好的设计方式先拿来用然后磨练过之后才扬弃。而不是整天价纠缠讨论于细枝末节。
解决方案九：
1写三层2B3B4C
解决方案十：
“做一个asp.net站点”，真正的“开发方式”在于那些东西之外，一旦确定好项目中的分工和各个任务评估、开发、测试流程就可以非常平淡而顺利地开发，接口、分工、流程根本上决定了开发方式，而不用再去讨论那种具体的“开发方式”（任何方式都可以采用），甚至也不用搞什么“标准化达标”运动也能保持极高的质量（超过CMMI4级的开发效率）。
解决方案十一：
有时是都把类库放在App_Code文件夹下的开发方式，有时是用三层结构来开发的。2.b3.c4.c
解决方案十二：
1，一般三层开发2，3 一般美工出图片，其余的自己来4CSS，DIV，table都用;
解决方案十三：
引用7楼sp1234的回复:
大凡真正的设计师设计产品，都是先考虑好需要的效果，然后再考虑如何制作产品的各个环节。正因为习惯于这种异于常人的思维方式，所以具有最强的接受能力，总是不论什么好的设计方式先拿来用然后磨练过之后才扬弃。而不是整天价纠缠讨论于细枝末节。
很有见地，sp1234
解决方案十四：
引用9楼sp1234的回复:
“做一个asp.net站点”，真正的“开发方式”在于那些东西之外，一旦确定好项目中的分工和各个任务评估、开发、测试流程就可以非常平淡而顺利地开发，接口、分工、流程根本上决定了开发方式，而不用再去讨论那种具体的“开发方式”（任何方式都可以采用），甚至也不用搞什么“标准化达标”运动也能保持极高的质量（超过CMMI4级的开发效率）。
您说的是大企业，具有很深技术基础的企业项目。现在我想基本上75%的企业应该还没法达到您说的这种水平。85%的程序员找工作也没那么好运气找到您说的那种分工确切的环境
解决方案十五：
例如一个产品经理在开发一个稍微复杂、“大型”一点点的任务时，它会先定义好子系统（例如前后台）通讯接口和验收规格的细节。然后前台某个交互组件的开发者会开发一个最轻量级的Mock（假的）测试模型来实现这个接口，借此作为支撑来开发、调试、测试自己的前台交互界面。而后台某个子系统开发者也会并行地具体实现这个接口，来处理真正的业务逻辑。最后，产品经理将它们“粘连”在一起形成最终的产品模块。这里，根本用不着考虑算不算“三层”的问题，不一样的项目管理技术细节决定了大方向，而不用“为了三层而三层”纠缠于这个概念。实际上，这类非常灵活恰当地进行分分合合、依赖倒置的设计“把戏”在一个项目开发中要重复几百次以上，所以不用见到一次就大惊小怪。不了解大型项目开发的人，以为项目只要设计一下数据库和几个静态页面，然后分解给几个程序员让他们从头到尾（到项目上线）“负责到底”这样粗放和简单地分工就可以保证开发工作了，对细节的把握连十分之一都不足，因此项目经理会要求普通的程序员都要学习项目经理才需要掌握的技术，他把自己的给做到位的设计、分工、测试、“粘连”的责任推卸给程序员来完成，然后自己事后再评论程序员做得“设计”好不好，评论程序员们该不该使用哪一种具体的“开发方法”。其实，只要项目经理搞好自己的本职工作，不用强迫程序员使用哪一种具体的开发方法，只要能够让所承包的每一个组件通过验收那么可以不择手段地使用任何开发方法，再有什么问题就应该是项目经理个人的问题。这才是应该放在开发中的第一个问题来明确。
解决方案：
引用3楼king19840811的回复:
12b3b4都了解
差不多
解决方案：
我说的“复杂、大型一点点”的任务，通常是指7天可以完成从“需求评估、设计、开发、测试、反复修改、集成到产品中”的整个一个任务，这个“大型”不是指所谓大型项目整体，而是指项目管理者的工作习惯、流程已经比较熟练而已。
解决方案：
例如在我们使用一个用户自定义的控件来向所有开发前台界面的程序员发布一个应用系统界面或者功能时，我们可以通过升级这个控件来提供更强的功能、更高的效率、更好的界面风格。而简单粗放地仅仅分解一下任务就分头开发，则并没有涉及组件、插件、平台技术观念，到底对“开发方法”的细节关注到哪一个层次根本不得而知，只知道这个方法很粗放（内涵很少外延很大）而已。
解决方案：
再例如所谓美工的问题。系统设计者如果有theme架构观念，那么所开发的产品可以简单地在页面上放置一个下拉菜单，由用户自己随时切换选择自己喜欢的风格。也就是说，可以在产品发布之后再不断地补充theme。因此美工既不是在产品开发之前，也不是在之后参与产品设计。美工和程序员在一定的框架、接口、插件、平台观念下被很好地既分工又合作。
解决方案：
引用14楼sp1234的回复:
例如一个产品经理在开发一个稍微复杂、“大型”一点点的任务时，它会先定义好子系统（例如前后台）通讯接口和验收规格的细节。然后前台某个交互组件的开发者会开发一个最轻量级的Mock（假的）测试模型来实现这个接口，借此作为支撑来开发、调试、测试自己的前台交互界面。而后台某个子系统开发者也会并行地具体实现这个接口，来处理真正的业务逻辑。最后，产品经理将它们“粘连”在一起形成最终的产品模块。这里，根本用不着考虑…
谢谢SP1234,连看了3遍才勉强看懂您写的。您回帖的时候呵呵最好一个长语句逗号下。一些东西我还没接触那么深估计一下子看那么长语句弯有点拐不过了。
解决方案：
顶SP1234，好人呐
解决方案：
这么快就停下来了吗？