三层架构中BLL应该传什么到UI
在三层架构中BLL层应该传单一的DTO(如DataSet) 还是自定义class好呢?如果传类似DataSet的单一对象 代码量少但没有了强类型,
如果传自定义class 代码量很大维护麻烦,但有了强类型。
大家都传什么到UI呢?
别跟我说用代码生成器生成出来的一表对应一类的对象。 --------------------编程问答-------------------- 使用DataSet,代码量大幅增加。
系统越庞大,维护量几何数的增加。一但修改表结构,系统没漫山遍野的改。 --------------------编程问答-------------------- 传datatable一类的人,多半是胶水程序员,他们就是绑定绑定在绑定,不用处理任何业务逻辑,全部业务逻辑就是crud,所谓的“程序”不过是编写一个自定义的查看器代替excel罢了。 --------------------编程问答-------------------- DataTable,Json,xml都可以传送数据,或者自己发明一个通信协议也可以
那种把数据写成User.UserName的才是胶水程序员,
明明设计文档接口已经说明了数据结构,还非要在代码中重复一遍,
难道说数据库100个表,你写100遍么?
再来500个统计报表呢?
恰恰是那种编写(代码生成也是一样的)所谓实体类的程序员,
满脑子数据驱动的思维,
如果不晓得字段,他们就写不出程序,
所以,所谓胶水程序员是指:他们年复一年的实现着相同的业务逻辑,只是外观和数据不同罢了,
重构对他们而言就是修改程序,而不是抽象业务逻辑用来扩展企业库
--------------------编程问答-------------------- ORM --------------------编程问答-------------------- 没有业务逻辑的(只是单纯的读数据库,展示出来)没有必要将datatable 转成list<T> 麻烦而且 转换过程还费性能
有业务的,个人认为转成Entity 还是必将方便和利于维护的
--------------------编程问答-------------------- 传类呀,传dataset好多不得手工写吗 --------------------编程问答-------------------- 讨论得很激烈,围观 --------------------编程问答-------------------- 除 --------------------编程问答--------------------
我现在项目是分布式的,接近有100个表,每个表写成类的话,这些类的数量起码要200个。因为要对应不同的UI写不同的类。维护这些类不会麻烦吗? --------------------编程问答--------------------
那就把你的不用写任何代码的业务逻辑放出来,让大家看看是不是真的什么也不用写。 --------------------编程问答--------------------
根据具体情况看(个人能力和使用场景)。
如果让胶水程序员做胶水程序,效率至少能保证,肯定需要牺牲可维护性,可扩展性,等。
无论胶水也好,真材实料也罢。让胶水的人做真材实料的活儿更困难。
这是Net企业级应用架构设计节选 --------------------编程问答--------------------
就上次回帖说的需求,你做一个给我看 --------------------编程问答--------------------
最后两句话正解
--------------------编程问答-------------------- 关键看lz 的 业务层的 复杂程度 来决定 采用什么模式设计 。
如果 你就是简单的 业务的话 ,改动不大 ,或者 就是做原型设计 ,那就用 最原始的面向过程式开发 也无妨
如果 业务 模型比较简单 且 跟 数据模型 能够形成简单的 一对一关系 ,就想博客 跟帖子 ,那就可以采用Catele.AcitvieRecord等框架 实现转换。
如果 业务规则负责,就采用 领域驱动设计好了。
--------------------编程问答-------------------- 100个表不代表有100个ViewModel类,实际上很多View是很复杂的,一个ViewModel可能会需要多个表的结构数据。
--------------------编程问答-------------------- 我的做法一般是传一个IResult<T>这样的东西 IResult<T>里面包含一个List<T> entities的东西 然后再包含一个message字段 这样就可以包含相当多的信息 而且因为本身就是个接口 所以可以复用 --------------------编程问答-------------------- 还有就是关于数据模型 前端的话用的应该是DTO 就是data transfer obj, 不闲麻烦的话每个页面一个 每个dto负责一个页面 然后在BLL就是domain obj 领域模型 针对具体的逻辑的 和db是无关的 最后在DB层才是data obj 映射到每个表
方便点的话 domain obj可以代替dto 只是在特定情况下 dto会更加方便些 --------------------编程问答--------------------
所以实际上这是一种三层映射, db到data obj, data obj到domain obj, domain obj再到dto, 这里最大的好处在于彻底的解耦,domain obj就是纯粹的业务逻辑, 和db结构 ui结构没有任何关系 所以说在这种情况下 完全可以抛开DB来开发
当然这种模式的缺点显而易见 代码量会很大 而且程序会狠复杂 不是特别大的项目的话应用这种模式就是自找麻烦 我在上个项目中别人的框架就是这样的 整个项目编译完2个多G 可想而知有多复杂了 --------------------编程问答-------------------- 俺们不管传啥子,bil重视的是逻辑和契约
ui什么什么滴和我写bil滴人不有任何关系。
我不会因为你一个UI上需要需要加个textbox,我就bil就加一个string属性。
我们写bil不认识UI滴,我们只知道契约和逻辑。一个部门员工登记操作。我管你UI怎么排做啥子?
我知道 员工对象,部门对象,他们的逻辑关系,然后有“登记操作”这个契约约定就可以开工了
呵呵,UI其实也一样,什么“代码生成器生成出来的一表对应一类的对象”,UI需要关心啥表吗?操作UI滴才不关心啥表呢,你就是把人员信息丢到一个二维码图上存着,然后用扫描枪扫出了人员信息这和俺做UI的人没半点关系 --------------------编程问答-------------------- 我就是用Entity的,手动写的,目前处理起来的确麻烦,要写很多类。同时又有另外一个问题,就是出id外全部用string类型,要不然,UI上会自动校验。 --------------------编程问答-------------------- 我认为每种架构都有他一个特色的地方,既然用了三层架构就是为了逻辑清晰,偏于维护。如果闲复杂、麻烦话你可以换一种架构。 --------------------编程问答-------------------- 倾向于传Class 代替DataSet
对于结构相同的类,可以抽象出一个基类,然后写子类继承之
对于需求变动,传参和返回结果,在修改上都较少
序列化 etc.. --------------------编程问答-------------------- 如果“自定义class 代码量很大维护麻烦”,那就不要用class了,因为class不是这样用的。 --------------------编程问答-------------------- 如果只是用于绑定之类的简单操作,传DataSet也未尝不可;存在一些数据操作,逻辑问题的,当然用class会更好。 --------------------编程问答-------------------- 围观,个人觉得看项目的需要 --------------------编程问答-------------------- ipnu b ipnu b --------------------编程问答-------------------- 除 --------------------编程问答--------------------
什么叫做“手动写的”?为什么会造成“全部用string"这种局面?
这说明你们的那种程序的层次,竟让以手工为足够、以一切都是string为足够,没有需求。 --------------------编程问答-------------------- 其实遇到这种问题,我就劝你去一个大一点的公司去实习。
或者如果你是上培训班来做所谓的“项目”的话(许多培训班其实就是在学生中选出一个“组长”来带领着做“项目”)那么不要相信你们的这个项目能真正教会你设计软件。 --------------------编程问答-------------------- 如果你无论编写什么程序,你都是 ADO.NET 加上 DataTable,就以这个业务class封装层次为极限,其实你在问题中讨论谁“效率高”之类的问题就没有意义了。
你没有那个需求,你从来不进行面向对象程序设计,还抛出这个问题干什么呢?
如果你的程序内部有100多个甚至更多个自定义class,这时候再来讨论这个问题,就比较有意义了。 --------------------编程问答-------------------- 我们的系统主要就是以DATASET来的.呵呵.处理比较通用性 --------------------编程问答-------------------- 我是胶水程序员,
所以我用 DataSet、DataTable.
--------------------编程问答--------------------
支持两位。
写与数据库打交道程序的。不会写存储过程的才是胶水程序员。 --------------------编程问答--------------------
支持P哥, 不面向对象, 就不需要提这个问题了!!! --------------------编程问答-------------------- 项目要看具体才需求,大的项目必须要分层要设计合力的框架,一切都要跟着你项目的实际需求来,如果要是一个业务逻辑很简单的项目,分层反而很麻烦 --------------------编程问答-------------------- 微软做[u]那么多事情,一大把的数据库中间件。
一把大的实体化数据库对象。
一大把的代码生成项工具。
为的就是让你们更快捷方便得想要的代码,达到目的(需求)。
人家都没限制你传递数据一定要用什么容器。可让你根据实际需求来变动。
你又何必去为这个没目的性的问题去纠结呢。 --------------------编程问答-------------------- 个人倾向DTO,可以和数据层解耦,弄数据契约
根据项目需求选择模式 --------------------编程问答-------------------- 一般传DTO,或者说是ViewModel,可以看一个三层架构的超市管理系统例子。 --------------------编程问答-------------------- 我也用dataset和datatable --------------------编程问答-------------------- 楼上有几位论坛里的老人,经常会在这类问题下说一大堆没用的——但是他们说的是有道理的——但是说了这么多还是没用,因为不给新人解决任何问题。用了DataTable并不一定是胶水程序员,不用也不见得是个什么鸟。关键是,你要知道为什么要用,或者为什么不用,不同情形下,此问题的答案是不一样的。我其实挺反感那些整天喊别人摒弃这些摒弃那些的人,因为任何技术都会变旧,因此用旧技术的旧系统总会存在,你不可能把每个系统都推翻了重搞一遍。
新手们也别被所谓高手们搞晕了,觉得多玄乎一样。说白了本质上不就是个统一接口,多个实现么,有他妈什么了不起的呢?所以啊,你们啊,too young, too simple. By the way, why the fuck I'm giving a shit to you guys... --------------------编程问答-------------------- 动软代码生成器 增删改查的撸过 1024 --------------------编程问答--------------------
我也支持你一下哥们,我也是胶水程序员,我就传给前台DataTable和DataSet --------------------编程问答--------------------
没有我们这群胶水程序员,怎么能体现出您是 XXXXX呢,实在找不到一个合适的词用来膜拜你了。只能用XXXXX代替了
如果你说你不是XXXXX我也没办法了 --------------------编程问答--------------------
1.小曹的原话的意思并不是说所有使用DataTable的就是胶水程序员;
2.我使用DataTable或者JSONTable传递数据,所有数据由驱动器向文档接口自动匹配,基本不需要人工编写相关代码,工作量根本就和数据对象的多少无关;
3.胶水程序员没什么不好的,因为就个人而言,只要团队人力资源策略合理,他会本能地使用自认为最"有效"的手段工作尽快通过测试,
而另一方面,如果团队的领导就是个不思进取的人,只想着廉价招聘一些"特种兵"来为其卖命,
而不是千方百计的为开发人员提供更高效的生产手段,
那么,他无权鄙视和侮辱在恶劣条件下辛苦工作的"胶水程序员";
4.不要把最新版本的vs或者C#当作是"先进的生产工具" --------------------编程问答-------------------- 这个。。。看实际需要而定吧。
我取LIST的时候比较喜欢返回DATATABLE,感觉不用去遍历生成ENTITY。
而取单个实例的时候就用ENTITY,DAL写了读取和生成的代码,比较方便。 --------------------编程问答-------------------- 我用类的,都是框架规定的 --------------------编程问答-------------------- 个人感觉传递class比较好,因为类是根据自己的需要进一步定义的 --------------------编程问答-------------------- 这里首先不是“应该传”什么的问题。其实有些人就是想靠纠结于原始的代码来消磨时光,面得有经验的项目经理要求他注重高效率地UI变化、要求他提高10倍以上速度编写类似linq式的查询计算语句、要求他经常改变数据层次结构、要求他掌握其他技术而快速变化。
我们看看这些人实际上都做什么工作就清楚了。如果一个公司根本看不到这些人在故意窝工,如果一个公司以为这些人的工资很“值得”,那么完全可以按照他们的喜好去写代码好了。而如果一个公司已经打算改变了,那么就赶紧改变不要犹豫。 --------------------编程问答-------------------- 面得 --> 免得
事实上有些公司的人就是在找理由让“框架规定”垮掉呢。这样这个公司就不会招聘更好一些素质的程序员了。 --------------------编程问答--------------------
人家说DataSet代码量大,而你说代码量小。其实这个就已经说明你平时编程时已经是多写了10倍的代码、多花了20倍的时间了。
如果不懂开发的人看不出“背景知识”上人与人的差距,那么就看实际效率吧。通过观察3个月,你也能看出不同人开发效率的差距。 --------------------编程问答-------------------- 小公司就是这样,没别的 --------------------编程问答--------------------
支持 POCO 对象,Code first 建模。DataSet 神马的,都是没想明白业务模型的。 --------------------编程问答--------------------
呵呵 --------------------编程问答--------------------
也不是说POCO就不好。但是POCO在C#的实现往往就是使用代码生成器,这导致了它观感不佳。但是在Ruby一类的动态语言,因为全部都是动态实现的,就显得很优雅。反过来说,如果C#不支持匿名委托和lambda,那么类似Linq那样的API估计也会很变态而无法使用吧。 --------------------编程问答--------------------
我的观点和做法恰恰相反,
无论是CodeFirst还是DBFirst,都是以一种实现依赖另一种实现,
这样做的缺陷是非常明显的:无法充分利用你的设计;
更有效的做法是:code和db都依赖设计文档接口,
这就和微软的强类型数据集的做法非常类似,
只不过微软仅仅为我们做了一个依赖接口的最简单的数据驱动而已
--------------------编程问答--------------------
今天在王垠的博客看到“珍珠效应”,觉得说得很赞。
http://www.yinwang.org/blog-cn/2013/04/14/terminology/
其实DataSet就是“珍珠”,它越是为了方便创建一次性的胶水代码而越是把数据和应用的耦合做的更加紧密。
在你的描述中经常出现“文档”(和通常意义的文档不同,你的文档是一种极端精确和细化的东西)、“工单”(我不知道这是什么玩意,听上去估计是User Story一类的东西吧,但是精确到代码实现的细节)。而你设想的(或者实践的)是一种非常与众不同的开发方式,有一个非常负责任的项目经理(或者团队Leader?我不知道怎么说,因为你的想法很独特),这个人负责把用户的需求细化成“文档”,并且考虑如何用代码实现,但是他却并不具体编写代码,而是把他的任务转化为“工单”,然后派发给“程序员”(我觉得叫“打字员”更恰当)。你的团队有大约十来个“程序员”。“程序员”不需要动脑子,他只要按照你的“工单”机械地编写出代码,他们的任务就是把你的设想变成精确的代码,而你的“工单”完全可以等价于“代码”,至少可以按图索骥地知道他们的工作是否正确完成。
你认为“程序员”在这种状态下就不会出错了。因为他们做的工作简单而且机械,有完全的预测性和可重复性。而那个“Leader”则可以出错,当他们设计有问题的时候,他们报废程序员的代码,并且“重复开出工单”。你的Leader不维护代码,他维护“文档”,当有了需求的变更或者设计的变更,他就着手修改和增补文档,然后将这些变更变成“工单”,让“程序员”去做。
听上去很复杂,但是如果我们把你的一些角色和术语做一点简单的替换,问题就简单了。我们把你的“Leader”替换成一个真正意义上的程序员,他编写的“文档”变成一种高级语言的代码(伪代码/配置文件,用代码生成器转化为代码),而你的程序员则全部被机器替代掉,他们的工作让编译器/代码生成器代替。至于你的“程序员”写的代码,谁关心它呢,那是编译器的中间输出。一切不言自明。
你把一个程序员就能搞定的事情分摊给了一群人做,你拒绝新技术的高生产率,而用人工代替机器和程序,美其名曰你找到了管理和为他们分配工作的好方法,而且不用担心他们“别出心裁”地耍心眼,事实上他们一点也不比机器忠诚和高效。你反复地说这个代码依赖什么,那个代码依赖什么,是的,他们不依赖系统实现了,却莫名其妙地依赖你的“文档”,所谓的文档就是一个你无法实现其编译器的,简陋而不严谨的,并且只有你一个人理解含义的语言。你通过控制一种谁也不理解的鬼画符拴住了一些只能按部就班编写代码的代码工,而成为不可替代的角色。
在你看来,一切新技术都是不受欢迎的,一切约定俗成的软件工程的方法论都是异端。这就是你的乌托邦。问题是你无法回避一个问题,你得养活那么多人肉机器,你的成本是高昂的。团队中只有你一个人在思考如何设计程序,你的工作是苦逼的。你的管理是集-散模式的,你的规模是有限的。当然,你可能是一个天才,但是你的方法如果强调了这一点,那么有什么借鉴的价值呢?除了满足你的倾诉欲。 --------------------编程问答--------------------
顺便我想强调下,我批判的是我理解你说的那套理论,而说实话,你说的东西比较玄,不排除很大可能性是我理解错误了你的理论。如果是我首先理解错了你说的那些东西,请你先纠正下这个,如果你觉得我理解你说的那套这个本身没有问题,再讨论你的那套东西。因为你不断在强调什么业务、设计文档、工单、抽象之类的词汇,但是又不符合常规的语境下它们本来的含义,这一点本身很让人费解。 --------------------编程问答--------------------
这些内容是你臆造出来的,和我们的生产方式无关!
软件生产可以不需要编写大量代码,更不需要代码生成器,
去找些极限编程,敏捷制造的资料好好学习学习吧(我也推荐过几本了),
顺便提醒你:选书前最好先了解作者的背景,
否则还是被像马丁富勒的《重构》这样的书绕进胶水程序员的怪圈;
还有一句,也是老生常谈了:
你已经习惯于动辄就歪曲别人的原话,然后嘲笑挖苦,这样不好,尤其作为版主 --------------------编程问答--------------------
真是不理解你的“生产方式”。但是“歪曲”和“臆断”,至少就对你的描述的理解来说,我真的还不觉得有什么责任,因为你自始至终都在用黑话描述着你的一切。 --------------------编程问答--------------------
我只是觉得,如果你不是故意故弄玄虚或者确实是无法融入主流学术体系的话,没有必要发明一套自己的话语体系。我不知道你阅读是否存在障碍,但是可以肯定的是,如果我们反过来,假设你是作者的话,那么能看懂你想说什么的人不会很多。 --------------------编程问答-------------------- 你不理解的话就是黑话?
是不是你的小圈子就是"主流学术体"?
你还是看看我曾经推荐的这本书,了解一下敏捷倡导者们是如何看待设计文档的再下结论吧
http://bbs.csdn.net/topics/390295614
这里是中文译本的相关信息:
http://product.china-pub.com/3663549 --------------------编程问答--------------------
好吧你们好友基情,我刚从泰山回来屁股还疼,看了你的话我的理解就是,在UI和逻辑层数据交互的这个过程通过文档约束好了就行了,
版主的意思是文档不应该由你来写。
给我的感觉就是你说你渴了,版主会给你一根烟抽,然后告诉你孩子吸烟有害身体健康。
我不喜欢跟版主交流任何技术上的问题,其实这个毫无意义,时间久了你就懂了,至于我为什么形容他是XXXXXX的原因你现在也能理解了吧?
你永远没有办法知道这个XXXXXX是什么,但是有一点我是肯定的,他是一个律师程序员。
--------------------编程问答-------------------- 顺便说一下版主,不要把你的那一套经验,建立在所有的环境中去用,不同的场合用不同的战术。
--------------------编程问答--------------------
你“推荐”的书和你说的那一套一点关系也没有哦。 --------------------编程问答--------------------
你不是不懂我说的设计文档,业务逻辑么?
这本书中重要的观点之一就是软件生产者对设计文档的理解;
你真的要放下一个评委的心态,
认真拜读一下软件生产方面的专家的著作,
比如:John Zachman的企业架构,PEM老板paul所著的CMMI与敏捷开发的整合
研究软件生产问题是你的职责,
需要循序渐进的提升的是团队的生产手段,
而不是关注C#又冒出哪些新特性,那是程序员的事情
我提供给你的信息已经足够多了,
学不学是你自己的事了 --------------------编程问答-------------------- 所以你就可以这样说了,我叫别人写代码,开发软件根本不需要写代码。 --------------------编程问答--------------------
对了,“生产”这个词也是你发明的词汇之一。 --------------------编程问答-------------------- 我的方式是:
关键对象用OOP思想去实现,不针对表,只针对业务对象。
而一般不需要大量处理的数据,信息也不是那么敏感的数据,就简单化了,不去构建模型了。
怎么方便怎么来。
我重视的是:
业务抽象模型企业库。 --------------------编程问答-------------------- 拜读了楼上的大神们激烈讨论,受益匪浅啊,每个公司可以做一套自己公司的规则,在人为的约束下,我觉得传递什么都可以,就算同样传递datatable,如果规则约定得好的效率必然也高,维护性也不会太差 --------------------编程问答-------------------- DataSet和DataTable能完成数据封装的功能,但是它有一个毛病,就是太自由,太不需要定义了,
任何一段Sql都可以形成一个独立的数据结构,但是这数据结构很可能不是有设计时定义的,而是由程序员在编程时定义的。
如果使用DataSet这样的结构,那么你最好在做一个数据结构的定义来帮助解析DataSet的数据,来防止在编程的时候随意地修改设计时所定义的数据结构。 --------------------编程问答--------------------
版主说的对啊 --------------------编程问答-------------------- 用类也好,DateTable也好,都说说自己的理由,别动不动就开始说用DataTable的就是胶水程序员,用Entity的也是胶水程序员,好吧,我知道你们都是胶水程序员。但是你们的理由呢?别引经据典谈什么著作,搞几个自己才明白英文、名词,你们自己都没自己的想法,没自己的理解吗?
代码是写给别人看的,不是写给自己看的,好吧,写段别人都看不懂,不明白的代码不算你本事。同样,作为码农的我们也应该清楚明确地解释自己的理由。别空讲,浪费大家时间 --------------------编程问答-------------------- 除 --------------------编程问答-------------------- 各位大神在此舌战数月。
其实问题就是,为毛需要三层架构!
--------------------编程问答-------------------- 为什么一定要说别人是胶水程序员,说别人胶水程序员来说明自己的牛B ,连最起码的尊重都不知道,鄙视。 --------------------编程问答--------------------
既然用了MVC,那应该也知道MVC的弊端
增加了系统结构和实现的复杂性。对于简单的界面,严格遵循MVC,使模型、视图与控制器分离,会增加结构的复杂性,并可能产生过多的更新操作,降低运行效率。
(2) 视图与控制器间的过于紧密的连接。视图与控制器是相互分离,但确实联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用。
(3) 视图对模型数据的低效率访问。依据模型操作接口的不同,视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问,也将损害操作性能。
(4) 目前,一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的,从而造成使用MVC的困难。
相信你也是因为MVC的好处才用的!如果嫌麻烦那就该架构了! --------------------编程问答--------------------
版主犀利啊 --------------------编程问答-------------------- 围观,个人觉得看项目的需要 --------------------编程问答-------------------- 说传datatable是胶水程序员的其实自己是自认为不是胶水程序员的胶水程序员.连datatable都用不好 --------------------编程问答-------------------- 挺能挖的,我说怎么一看内容曾经看过。 --------------------编程问答-------------------- 讨论太激烈了,吃不上嘴啊! --------------------编程问答-------------------- 这个我觉得要看实际情况
如果BLL使用得比较多,定义成对象会更方便些,也符合面向对象设计;
如果BLL层只是作一个数据传递,没什么复杂逻辑的,用dataset传递也未尝不可。 --------------------编程问答-------------------- 理想的情况是传 只是用于展示的数据?
实体?XML?JSON?
--------------------编程问答-------------------- 读过,各位牛人说的全有道理
不懂什么是BLL层只懂Structure(牛人叫什么Model)和DAL,感觉这个用起来还是很不错的.
规矩是死的,用的还是人啊
数据库还讲什么范示呢,俺数据库就500条数据,冗余一下行不?
数据库就几张表而以,关系也不复杂性,用DataTable咋了?
我感觉上面的都是特定的环境做了特定的事,那样做可以,这样做也可以,一但离开了特定的环境那么就要遵循一个好的规则.
支持caozhy版主,使用三层结构,那位牛人能告诉我一下BLL层是什么东东,我在UI层的代码就是BLL吗?呵呵! --------------------编程问答-------------------- | View -> controller (View和Controller都可以理解为controller)| -> Business -> DBLayer
Business 里面会做业务处理,返回的是业务数据,比如用户信息,联系人,公司的信息等等。
View 只负责化界面,将业务数据展现到界面上。 --------------------编程问答-------------------- 看了那么多,反而把我看头晕了,给楼主的几点建议吧:
1,大牛的话需要听,但不需要做;因为技术、立场、思考方式差距太大,你无法生搬硬套。
2,注意给你提具体解决方法的同学,不一定能解决你的问题,但一定会让你有更多的解决方法。
3,目标要明确,你是来解决当前问题的。 --------------------编程问答--------------------
╮(╯_╰)╭
能驾驭啥,就用啥。 --------------------编程问答-------------------- 根据你自己的能力,还是需要学点深入一些的东西的。有些借口是无头苍蝇式的。 --------------------编程问答-------------------- 任何事情,如果你没有做过(相当高强度地在真实项目中实验过),你可能都会缺乏主见。
学会用别人的思路去指出别人的问题,才是真正学会了。如果你总是用自己的理由(甚至什么“你说的我听不懂,所以我不学”),那么就难免成为无头苍蝇、它只能围着一些垃圾“嗡嗡嗡”闻一闻,而搬不动。所以你要能得到自己的做法,需要实际去“做”,而不是仅仅抄袭。 --------------------编程问答-------------------- 关注一下,值得学习学习 --------------------编程问答-------------------- 全用DataTable,好吧,你犀利,你做的时候可以少写一些代码(其实你真少写了吗?这些Model都有工具可以直接生成的。。),好了,功能上线,运行稳定,perfect
半年后。。。。新需求来了,要求修改功能。。加了个字段,很好,还是以前都是DataTable,好多方法不用改,太棒了
==,这个DataTable包含了什么东西,我看看,哦,是这个。。。。还有那个。。。。还行,好吧,继续上线,运行perfect
再半年后,辞职。。别人接手。。。。
功能开发。。。尼玛,都是DataTable,里面包含了什么??不知道。。。我需要去看DAL...看完了知道了。。。改了几行代码,尼玛。。。这个字段名是什么。。。我得再去看看DAL...
。。。。。
。。。。。。。。。
。。。。。。。。。。。
尼玛的这是多坑爹的事情啊。。。。。 --------------------编程问答-------------------- 你能用Spring EF等就用Orm
不会么? 就用代码生成器 自动生成类结构
再不会么? datatable 拼sql总会吧
个人认为视自己能力而定··大牛的思想凡人是跟不上的
--------------------编程问答-------------------- 看了之后发现我是个胶水程序员啊 我艹 一般都是datatable + sql 拼装
有时候用到List<model> ,Dictionary<string, string> 等
数据库查询频繁 但不是太复杂 用存储过程
一般还是ADO.NET
触发器 木有用过
查询表多 偶尔用到视图
尼玛 我胶水程序员看来在这家小B公司 不能再混了 再混一辈子都是胶水程序员 是不是啊
面向对象 我也不知道接触了没 反正就那样 用Model分装几个实体 然后new 实体 按条件查询显示
是不是很水啊 求大神指点 我现在该怎么做 跳槽去别的公司学习深造 还是直接放弃.net呢
鞠躬 请大神指点~ --------------------编程问答-------------------- 传什么不得看UI 需要什么类型么?都已经到UI了 就差绑定了 难道还需要做很多处理么? 那要底层干嘛 --------------------编程问答--------------------
--------------------编程问答-------------------- 同志们讨论的很激烈。
个人认为,SQL + DataTable 确实可以把项目做出来,但可维护性,可重构性相对较差;有的时候迫于各种压力和条件限制,这可能是比较快速的处理方式。不过,这种项目,维护起来,比较吃力,特别是出现人员切换,比如出现有人离职,或者转到其他项目等,对于接手的人来说,犹如梦魇。不过这种方式,也有一定的好处,特别是对于刚出门的开发人员,执行一条语句以后,马上就可以看到执行结果(DataTable),比较“实在”。如果一上来,就弄 MVC + ORM + IOC 很容易把人吓退了。
楼主如果已经对这种方式比较熟悉,可以考虑深入一下,使用一些框架,比如NHibernate,Spring.net,Ninject。
--------------------编程问答-------------------- 除
补充:.NET技术 , 分析与设计