c#开发中三层架构怎样分工
不可以按层来分工。 所谓层是一种横向的“逻辑”结构。并没有实际存在一个物理边界，而且分层只是为了在编码的时候，用来衡量某些代码放在那个逻辑层上。换句话说，分层只是在编码的时候树立其一个考虑问题的模式。如果按一般MVC的分割层次关系。那么实际功能往往是从界面输入（View层）- 逻辑代码处理(C层)- 数据读写(Model层)，最终还是会回到界面层。如果按层分工的话，就要每个人要求理解所有的实际功能需求在自己负责的那个层所需要做的工作。同时还要进行抽象。这样的做法绝对是让人绝望的。真正编码的时候，最容易入手和理解的，就是从实际功能需求出发。然后每个成员分配功能需求去实现编码，同时有人负责总体架构维护。实际功能的实现，在整个代码结构中，是纵向的。虽然代码会贯穿全部的框架，只要有一个成员能够总体负责和控制框架设计，那么一些代码越界，比如View代码放到C层，或者是一些重复代码，相似代码的编写都可以通过重构的方式消除掉。最关键的是，编码的成就感。按需求出发，开发人员会有足够的成就感。“哇，做好一个功能。哇哦，又做好一个功能。哦哦，又完成一个功能，我好牛逼啊。”如果按层分工，多半会这样“靠，我要的这个函数，你还没有写好” --View层“NND，我这个函数不是这样调用的” -- C层“你们传递的数据格式是不对的” -Model层就酱，自己选吧。HOHOHO！
■网友
我个人不太赞同开发过程中分工太细，软件工程是个很复杂变化很快的东西，难以按层次分工，反而容易出现看着别人加班加点自己干完独自潇洒的情况就拿普遍的View-BLL-DAL的模式来说，要是有三个人一个人开发一层？那搞View的又得写js又得写aspx，DAL得负责所有的sql，BLL往往是最轻松的从项目本身来讲，各个工作的工作量都是不相同的，怎么划分都不是很完美，这很考验项目经理的能力从人的角度来讲，分工越细越容易出现怠工推脱的情况，一旦分工细了，就可以大大方方的说“这归xxx复杂”而推脱；另一方面，如果一个人只关注一方面，人员流失带来的损失也很大对于小型团队的B/S的项目，我个人的建议是：首先，把系统结构设计出来，美工和数据库的人员都得参与，讨论好了之后得保证界面设计、业务逻辑、数据库结构都达成一致然后，美工得会HTML+CSS+JS，设计的时候就从HTML角度出发，而不是整天对着PS，首先就用HTML搭出大体结构（方便开发人员填充数据看效果），然后再设计细节效果然后，美工设计的同时数据库也得开始搞，最好能手工录入些数据之后显示到界面上形成初步的DEMO来验证前期设计是否正确，以保证早发现问题早解决然后，开发人员就得施展拳脚了，数据访问类，实体类、业务逻辑、展示到aspx，一级级的做，分工嘛，混合进行，谁慢了闲余的人员就补上，这样保证某一块内容不是只有一个人清楚，让大家都能了解整体架构最后，进行整体测试的时候，各方人员都得参与主要要表达的是：美工、前端、aspx、aspx.cs这些都是混合的，不能美工只管ps肯定是搞不好的，美工的职责不是出图，而是整体网站页面，跟程序结合、seo、兼容性都得关注的；数据库人员也不是就写写sql了事，不能为业务服务的sql都是废品，数据库人员必须写业务代码；其他开发人员也是一样的，bll的得交叉写view和dal，dal的得熟悉开发、维护数据库对于中大型团队，没有经验不敢妄言最近刚出了篇文章推荐给提问者看看，作者观察星巴克的感想，星巴克没有职位之分，所有人既打扫卫生又收银又干XXX，貌似肯德基也是这种模式题外话：软件开发行业总是喜欢整天学习研讨各种“先进的”各种各样的模式、理论，好像习得某种武功就天下无敌一样，而实际上大部分都是刷存在感、哗众取宠、不合实际的，就拿分工问题来说，本来就应该要求员工技术精湛、涉猎广泛、认真负责，分工过细就是纵容员工偷懒、内讧、推卸责任，而很多从业人员还把只做的了一点点事情当成分工如此、理所当然，不得不说是整个行业的悲哀，也难怪人家星巴克、肯德基能做到全球在星巴克买咖啡思考技术团队的管理
推荐阅读
- |奥迪开发基于C-V2X校车警示系统
- 汽车|长安汽车：公司与华为、宁德时代三方正在联合开发智能网联电动汽车平台和产品
- 啥是微信开发WEB前端
- 做苹果开发，想买台MacBook，大家建议买啥
- 开发／维护 一个类似qq会员或者Amazon Prime会员的会员系统有哪些难点和挑战
- web开发，一般项目经理从项目中拿多少项目奖金
- 趣头条|海外媒体称大众正在开发两款基于MEB平台的小型车 ID.1与ID.2
- 咋搞垮一个Onlinejudge
- 盐城经济技术开发区：“创成”即启程 创建再出发
- 汽车|国产SUV鏖战 为什么说“大心脏”的能获胜？参数不玩虚的丨动力之强 数据说话基因不是盖的丨沃尔沃同款发动机，豪横调教得是精的丨成熟的手法