问题描述
小弟初学三层+工厂模式,发现用起来有许多地方不是很明白.请高手接单1.这个模式下面,数据库的视图如何使用.因为视图没有专门的model对象.难道要为视图建立对象吗.还是不提倡用视图.2.一些页面的gridview显示的内容,可能只要一个表的几个字段,不需要全部.如果用dal去查询,返回的model对象的话.是否数据量就太多了.也浪费了.要如何处理.3.更新数据的问题,比如我只要更新一条数据的一个字段.有没有简便的方法.难道一定要getModel以后,更改一下再update进去呢.因为事实上,更新一条数据的一个字段.我只要知道数据id,和字段的值就好了.希望高手指点以上三个问题.
解决方案
解决方案二：
推荐你使用LINQToSQL。Linq实现了非常轻量的Model和DAL。
解决方案三：
1.应付数据库中的视图,可以用DataSet2.完全可以自由获取你想要的字段数据。针对这个问题，你可以多看看别人的DAL层代码3.voidUpdate(Foodfood)符合面向对象编程，这个传递对象的这种方法对于更新多个字段很受用。当然，你可以用你的方法，三层不是规矩，是解决问题的方法，看情况而变。使用LINQ更新，它就非得要你传递一个对象
解决方案四：
引用楼主vaete的回复:
1.这个模式下面,数据库的视图如何使用.因为视图没有专门的model对象.难道要为视图建立对象吗.还是不提倡用视图.
什么意思？实体对象什么时候成了你的某个软件的附庸概念了呢？实体作为表现层跟业务逻辑层通讯的对象实体，它是从实用出发的。比如我们要设计一个“csdn在一周以来出错情况”的报表，那么这个报表、或者出这个报表的业务逻辑中所需要的实体我们就可以说出来，至于在设计时去纠缠于这些实体是不是有什么关系数据库表的对应物，纯粹是无稽之谈。
解决方案五：
你如何分析和设计面向对象软件的需求和流程？靠关系数据库建表么？
解决方案六：
所谓的“三层、工厂”之类的，是无数实际工作之后的抽象出来的东西，所以它不会去纠结于数据库表、数据库视图的问题，否则就不是抽象了。你只应该问问站在底层实现的时候自己反而不会用数据库视图的问题，看看你使用的所谓实现方式是不是让你丧失了这个能力，比如看看LinqtoSQL是不是就有这个毛病。但是毛病不是出在“三层、工厂”上，是出在底层。
解决方案七：
感谢各位给我的解答，我明白各位的意思了。是我太纠结于model去对应数据库中的表了。不过如果之这样，是否会在开发的时候无形中增加了很多对象。比如说，数据库的产品表，我原先有个对应的model。然后有个产品＋销售量的视图。我是否又要创建一个实体model去对应他呢。这样是否会很累呢。我就是感觉这样做的话，多层开发反而不方便
解决方案八：
引用6楼vaete的回复:
感谢各位给我的解答，我明白各位的意思了。是我太纠结于model去对应数据库中的表了。不过如果之这样，是否会在开发的时候无形中增加了很多对象。比如说，数据库的产品表，我原先有个对应的model。然后有个产品＋销售量的视图。我是否又要创建一个实体model去对应他呢。这样是否会很累呢。我就是感觉这样做的话，多层开发反而不方便
这个是必然滴，实际上下面我要说的可能就是sp1234大大比较反感的，模型对象分类DO，DTO一类的东西，实际上我也是一个比较关注抽象的人，也觉着的确没啥必要太过区分这些东西，只是实际应用中viewmodel，dto这类东西到却是是真实存在的正好昨天在博客园看了一篇博文《谈谈对于企业级系统架构的理解》http://www.cnblogs.com/liping13599168/archive/2011/05/11/2043127.html虽然也是老生常谈的东西，但是博主本身为你展现了一个渐进的过程。一个从抽象到具象的渐进演变过程只是我们态度是不要刻意去最求那个最终结果，那个结果是根据条件渐进演变滴，没有那个渐进的过程，你想一步就过去话，正好又是另外一个幽默“步子太大了，容易扯着蛋”
解决方案九：
你如果不用视图，你写出来的东西基本都是报废的。你说麻烦？楼上有人说，用3.5的LINQ，你可以试试。那都是用控件直接拖动的。而且代码就几句，类已经方法实现，微软都帮你写好了。但是问题是你看看功能实现以及问题所在吧。底层很重要，楼上说的对：“步子太大了，容易扯着蛋”up↑
解决方案十：
学习。
解决方案十一：
引用9楼lixiaolian7的回复:
学习。
xuexiing
解决方案十二：
Linq实现了非常轻量的Model和DAL。
解决方案十三：
1,可以将视图影射成Model；2，可以仅读取Mode的部分属性，如的用法：Useruser=newUser();OQLq=OQL.From(user).Select(user.ID,userName).END;List<User>result=EntityQuery<User>.QueryList(q);
3,可以仅仅更新Mode的部分属性：Useruser=newUser();user.UID=3;//设置主键的值user.Age=20;EntityQuery<User>.Instance.Update(user.Age);//仅仅更新Age属性
推荐楼主用用我的框架
解决方案十四：
呵呵，楼上的一直在推荐自己的框架，不知你的框架是否商用了，有无bug
解决方案十五：
引用13楼zhuawang的回复:
呵呵，楼上的一直在推荐自己的框架，不知你的框架是否商用了，有无bug
详细情况,请看官网说明：http://www.pwmis.com/sqlmap框架是来自多个项目的经验总结，并且受到了众多网友的肯定，已经有不少朋友获取了源码，官网有说明。由于来自实际商业项目应用，可以肯定发布的版本没有Bug。
解决方案：
当初我也有楼主的困惑，也被领导盲目的要求累得半死，所以我一气之下自己做了一个框架，并宣传给其他朋友，让大家都能够轻松开放，彻底摆脱数据开发的问题，只需关注与业务逻辑与界面的开发。
解决方案：
我们公司也有一个你类似的框架，而且也有一套工具可以快速的生成各个层代码，只要稍作修改就可以操作数据了。当时公司的框架返回的是DataTable，不是List<User>和User这样的对象集合和对象。我还是有和楼主一样的疑问，如果是返回对象的话，是否要为所有的视图生成一个实体？
解决方案：
回zhuawang：是否将视图生成实体看业务需要，不要将实体类和数据库表、视图等同，实体可以映射到一个表或者多个表，复杂的查询，视图，存储过程等，可以简单的认为，实体就是系统中要使用的数据载体，这些数据可以从数据库来，也可以从XML文件或者其它地方来，也就是，不要DB=>Entity而是Entity=》DB否则你会纠结于数据库的设计，而无法体会到OOAD的优势。
解决方案：
引用17楼bluedoctor的回复:
回zhuawang：是否将视图生成实体看业务需要，不要将实体类和数据库表、视图等同，实体可以映射到一个表或者多个表，复杂的查询，视图，存储过程等，可以简单的认为，实体就是系统中要使用的数据载体，这些数据可以从数据库来，也可以从XML文件或者其它地方来，也就是，不要DB=>Entity而是Entity=》DB否则你会纠结于数据库的设计，而无法体会到OOAD的优势。
谢谢你的解答，我明白你的意思。我也够懂的就是如何设计这个实体吧。我们公司的ORM只是简单的对每个表生成实体类。好像Nhibernate也是吧。不知道你的框架是怎么生成实体的。如果是用工具生成的话不也是只能从数据库表来对应生成吗？
解决方案：
目前大多数ORM工具都是从数据库生成实体的，如果先有实体类，再映射到数据库，工具支持比较困难，这也是“CodeFirst”的不足之处，不过现在最新的EntityFramework已经可以支持CodeFirst了。PDF.NET数据开发框架的实体类工具目前还只能提供从数据库生成实体的方式，支持将表、视图甚至复杂的SQL查询语句映射成实体；当然可以先有实体类，不过需要你手工去做映射关系（EF将这个过程自动化了）。
解决方案：
引用19楼bluedoctor的回复:
目前大多数ORM工具都是从数据库生成实体的，如果先有实体类，再映射到数据库，工具支持比较困难，这也是“CodeFirst”的不足之处，不过现在最新的EntityFramework已经可以支持CodeFirst了。PDF.NET数据开发框架的实体类工具目前还只能提供从数据库生成实体的方式，支持将表、视图甚至复杂的SQL查询语句映射成实体；当然可以先有实体类，不过需要你手工去做映射关系（……
能发一份你的框架的源码给我吗？我的邮箱:zhuaone@foxmail.com