问题描述
大家好，做软件好多年了，一直给人打工，最近萌生了想自己做个开源框架的想法。工作多年，也接触了一些公司和产品，来这里听听大家的想法，集思广义，希望作出的东西好用些，尽量借鉴一些已经开源的做法。我先说说需求吧：1、首先定位成轻量级的，不要搞太复杂2、满足一般的网站、企业管理系统即可。3、要适应跨平台需求。4、要足够灵活，支持用户级别的自定义需求，包括流程、报表。表单的自定义需求待定。5、因为从业多年一直是.NET路线，对其他语言虽有接触但不熟，还是做.NET的吧，做自己擅长的。最近考虑了一下，初步选用组件如下，有较多待定项:1、语言：使用asp.net+IIS+.netframework2、开发模式：MVC，可能需要改进3、数据库：mysql（主要考虑跨平台）4、数据库管理工具：phpmyadmin（apache部署PHP）5、日志：log4net6、UI框架：待定7、报表工具：待定8、工作流框架：待定9、跨平台部署：采用MONO，服务器待定10、是否选用AOP：待定11、是否选用nhibernate：待定12、是否选用IOC容器：待定
解决方案
本帖最后由 devilzh 于 2016-06-16 22:17:25 编辑
解决方案二：
做事情不是靠“指令分解”，而是靠市场调查。所有你说的这些，能把其中20分之一做好，就能成功。如果多做几样，必定失败。这就是一个码农跟架构师的区别。前者，一看就是闷着头对概念进行分解。后者，一看就是基于市场调查，随时可以重构。
解决方案三：
你把一些概念和代码堆起来，不能成功，只能自己陶醉几年。如果你想搞一个开源框架，要先学会从外部来看待自己的框架，就好象一个女人是从镜子里、别人眼睛里看自己美不美，她才能各个都学会极高明的化妆技术。如果都是闷在家里只想堆砌一些东西，那她就会画得很丑。
解决方案四：
引用1楼sp1234的回复:
做事情不是靠“指令分解”，而是靠市场调查。所有你说的这些，能把其中20分之一做好，就能成功。如果多做几样，必定失败。这就是一个码农跟架构师的区别。前者，一看就是闷着头对概念进行分解。后者，一看就是基于市场调查，随时可以重构。
我只做过程序员，没有做过架构师。目前的想法，主要是根据以往的工作经验所得，可能有不妥之处。万事开头难，做什么事都要从一点一点做起，我发帖的目的时希望给自己的开始做个规划，听听别人的想法，而不是直接钻进去。。。
解决方案五：
我个人的观点，是你找比较好的公司再打一次工，如果所幸能够找到好的老板或者同事，“开窍了”，于是把你设计的的最新的系统作为开源框架。这样的框架从公开给大众的那一天就有一些真正的技术价值。不要把任何人都知道的入门知识作为“框架”来罗列。一个项目的核心，在于那些机密的东西、困难的东西、一般人一下子明白不过来的想法。你来罗列一些每一个人都能随便搜到的东西，这只会消磨时光。
解决方案六：
引用2楼sp1234的回复:
你把一些概念和代码堆起来，不能成功，只能自己陶醉几年。如果你想搞一个开源框架，要先学会从外部来看待自己的框架，就好象一个女人是从镜子里、别人眼睛里看自己美不美，她才能各个都学会极高明的化妆技术。如果都是闷在家里只想堆砌一些东西，那她就会画得很丑。
其实做框架不是目的，我也不想证明自己技术怎么样，只是希望以这个起步，在做的过程中，逼着自己去学习，完成自己的技术积累。开源的目的，是不想闭门造车，最后只出来一个自己为是的东东，陶醉在自己的世界里，那就没意义了。
解决方案七：
引用4楼sp1234的回复:
我个人的观点，是你找比较好的公司再打一次工，如果所幸能够找到好的老板或者同事，“开窍了”，于是把你设计的的最新的系统作为开源框架。这样的框架从公开给大众的那一天就有一些真正的技术价值。不要把任何人都知道的入门知识作为“框架”来罗列。一个项目的核心，在于那些机密的东西、困难的东西、一般人一下子明白不过来的想法。你来罗列一些每一个人都能随便搜到的东西，这只会消磨时光。
其实框架这个东西，说白了还是技术，是为业务服务的。我们的最终目标是用它来实现我们想做的东西，同时又能减轻我们的工作量，适应不同的需求变化。至于机密的或者困难的，无非是实现方式不同而已，并不影响最终目标的达成，这个不是我想追求的目标。我想要的是有，好用即可，而不是技术有多高深。
解决方案八：
从你眼中看到所谓的"框架",无非是集成了N多"插件"的"解决方案"而已...或者说,你经过经验的积累写出了很多通用的"class",都集成在了解决方案里.你会跟你公司新来的人说:"用这个,我写的框架.."但是实际上,框架并不是你理解的而已.
解决方案九：
引用7楼diaodiaop的回复:
从你眼中看到所谓的"框架",无非是集成了N多"插件"的"解决方案"而已...
有点这感觉。MVC本身就属于框架，只是在扩展一些方法而已。不过楼主的想法比较接近CMS的模式有木有？市面上太多这样的东西了
解决方案十：
应该针对市场的方向来开发特定的框架。也就是，你希望你的框架是干什么的。wms，cms?等等先明确你的市场方向。在考虑需求。
解决方案十一：
看得出，你主要还是在做组件的拼凑，这很容易把一个框架做烂。如果一个框架只是各种技术的杂合，那么你会发现，它学习曲线高，架构臃肿，使用繁琐，灵活性差，性能低下。因为一个好的框架，它采用的技术必须有主有次。比如工作流，AOP，IOC，这些东西很可能在一个框架里只在很小的一个范围内使用是合适的，而你如果将其推而广之到了整个架构中去，那可能就是灾难。
解决方案十二：
之所以选了很多现场的组件，是不想从0做起，毕竟很多开源的前辈已经有了很好的解决方案，没有必要再把前辈们踩过的坑再踩一遍。选择这些组件，是希望借鉴这些组件的理念和长处，融汇贯通，融入到自己的框架中去，毕竟每个组件都凝聚了其他人的心血在里面，都有很多值得我们学习的地方。9楼说的不错，市场决定需求，需求决定方向。技术是为业务服务的，始终应该以需求为导向。但我现在的需求方向虽然不是很明确，但有一个大致的方向，那就是面向一般的企业门户，MIS系统，其实是比较低的一个要求。我对框架的理解可能不到位，但我需要的是可以独立于业务，能够支持快速开发，在较短的时间内，以尽可能小的代价为交付一个产品提供支持的一系列组件。这些组件能够处理业务之外的其他工作，可以让开发人员专注于业务逻辑的处理。现在的方向不是非常明确，但不想等着一切都明确了再动手，早一天动手，早一天积累。
解决方案十三：
用户角色权限管理数据的快速展示方式比如数据双向绑定机制通用页面祖先类的构造，比如基础数据列表和编辑窗体，单据列表和编辑窗体下拉列表数据的展示方式整体页面框架的搭建业务逻辑层面，如何合理的进行分层，实现DAL，BLL层......这些工作量会占用你框架的80%以上的工作量，而你提到的这些技术，说实在的，已经非常完善，没有太多还需要再封装的功能，基本上拿来就用就ok，像MVC，Hibernate，log4net。而像AOP，IOC这些东西，纯属锦上添花，某些特殊的场景用用就行，也是拿来即用，并不需要多少工作量。
解决方案十四：
我尿了，大家都尿了。支持有梦想的人支持梦想更有行动的人。
解决方案十五：
引用12楼daixf_csdn的回复:
如果目标是要做快速开发，使开发人员专注业务，那么其实这个框架最重的工作，并不是你提到的这些技术。而是大量的业务层面的基础工作，比如：用户角色权限管理数据的快速展示方式比如数据双向绑定机制通用页面祖先类的构造，比如基础数据列表和编辑窗体，单据列表和编辑窗体下拉列表数据的展示方式整体页面框架的搭建业务逻辑层面，如何合理的进行分层，实现DAL，BLL层......这些工作量会占用你框架的80%以上的工作量，而你提到的这些技术，说实在的，已经非常完善，没有太多还需要再封装的功能，基本上拿来就用就ok，像MVC，Hibernate，log4net。而像AOP，IOC这些东西，纯属锦上添花，某些特殊的场景用用就行，也是拿来即用，并不需要多少工作量。
非常感谢，提了需要比较实用的建议，你说的这些正是我所需要的，AOP，IOC这类东西也是我暂时待定的内容。下面那些组件，我的观念也是借鉴实用，不想自己从头研究，封装谈不上，但我不想把这个东西弄的一个大而全的很重的东西，所以还是希望对底层的东西有所了解，在别人的基础上进行简化，或者借鉴思路写一个简化版的。一方面可以积累知识，一方面对底层代码能够了解，便于以后使用过程中理解更加审核。
解决方案：你列举了一堆“框架”用他们搭建出来的东西显然不能再称为框架了所以，你到底想做什么？
解决方案：引用15楼shingoscar的回复:
你列举了一堆“框架”用他们搭建出来的东西显然不能再称为框架了所以，你到底想做什么？
我想要的东西，前面已经说了，叫什么东西无所谓，关键是有其价值就行。
解决方案：撸主别听他们比比，按照你的想法来
