快过年了，大家可能都很忙吧！？可是一直有个问题困扰着我，希望能在年前解决掉。要是高手们有空就帮帮小弟我吧，谢谢了！
三层架构中，多表连接查询中实体类和实体访问类改如何写呢？最好能有实例。不要说让我看petshop哦，我实在无法消化那么专业的。给个简单的实例，谢谢了，等我弄懂了简单的再去看petshop吧，谢谢了。找了很多资料，但是关于多表查询这方便的资料实在不多啊！希望高手不要吝啬你的代码，给小弟一个指导！谢谢了祝大家新年快乐。
三层架构中，多表连接查询中实体类和实体访问类改如何写呢？最好能有实例。不要说让我看petshop哦，我实在无法消化那么专业的。给个简单的实例，谢谢了，等我弄懂了简单的再去看petshop吧，谢谢了。找了很多资料，但是关于多表查询这方便的资料实在不多啊！希望高手不要吝啬你的代码，给小弟一个指导！谢谢了祝大家新年快乐。
你只要对数据集操作就行了
用链接字符串查询返回结果
和单表连接相同 只不过查询语句复杂点
不是都是DataSet吗？
但如果用的NHibernate的话,可以用HQL来实现关联查询
也不是短时间能够完成的，
楼主花这些时间不如老老实实研读一些老外的OO基础书籍和UML书籍，
模仿petshop宠物店模式来构建生产用的设计架构是急于求成拔苗助长的行为，欲速不达。
呵呵，这么多年来我一直没有闲心（花时间）去看petshop源码，只是看一些人的介绍和评论，我总感觉我自己不值得花时间去看Petshop。不过因此也许正好可以更你一样的背景、视角去看这个问题。其实这跟你的DAL设计有紧密的关系。不同的DAL背景知识，肯定会得到不同的回答。例如Linq来查询关系数据库，它会支持Join、SelectMany，以及许多其它操作符，可以跨多个数据集，然后在底层自动翻译为关系数据库的查询，它自然地支持了你为多表的连接查询结果所设计的实体类。那么原始一点，假设我们手动使用ado.net去访问关系数据库，我们可以手动去写SQL查询，然后将DbDataReader所查询出来的一行行数据按照字段写入一个个对象实体的字段（属性）中。或者既不使用高级的带自动编译机制的Linq，也不采用低级的根据每一个具体应用和具体数据库而手动写SQL语句的做法，我们取中间策略，假设只有涉及单表的DAL查询机制，我们可以在BLL中先查询出一表然后foreach循环并查询另一个表，分别调用两个单表查询DAL功能，把数据在内存中做关联操作，然后将结果装到你设计的多表查询实体类中。
最终我要说的是，其实设计实体类不要从关系数据库出发，应该从表现层的需求出发。在设计表现层的时候，我们应该抛开关系数据库表设计的纠结，直接写出业务所需求的实体类来。管它是多表还是单表？这才是重点。
我是用sqlhelper组件负责数据库的访问。
我是第一次做项目，跟着老师干，可能是水平还没到家。在家里就胡乱自学。渐渐有些方向了。也想趁这个机会多学一些。特别是向你们这些前辈们学习。
因为这个业务基本上都涉及到了多表查询。但是一般的书上都介绍的是一个表对应一个实体类。所以我突然发现自己无从下手了。
我知道我这个东西用拼字符串的方式就可以了。
但是考虑到系统以后的升级。
毕竟不是我去弄了，我想让以后升级的人稍微方便些，而不是去重新做一个。
我目前的参考是资料是精通asp,net企业级项目开发。但是发现，我的需求和它还是有些差距的。
不知道您能否推荐些有用的资料呢？
谢谢！！！
我想根据我了解的三层的思想用到自己的实际项目中去
但的确是有些急于求成了，
整个架构还没有什么方向。
所以想向大家请教。、、
这个系统虽然比较小。但是需要处理比较多的数据，特别是查询，（这些数据由于别人的数据库设计的有些不合理，因此总是牵扯到大量的多表查询）还需要报表的应用。
我想架构好了，方便以后的升级开发！
另外的话自己也可以趁着寒假学点东西。
但是时间短，对于一个新手来说，任务还是有点重的，因此在这里求助于大家的！
希望你能谅解……
2、这也是中国IT教育的悲哀，学校里没人教这些。
另外多于多表查询，用人建议我用视图。
那么我应该是用sqlhelper去访问这个视图呢？还是我的业务层去访问呢？
或者是其他呢？
那么对于存储过程呢？
也是业务层直接去操作吗？我真的很无知，课堂里的东西没有深刻理会，现在又静不下心来去理解
我真的不想成为受害者，或许我需要一个好的引导者，这个人我知道不是我自己是你们呵呵
1、一方面，微软在几个有着个人签名痕迹的技术上（如linq、mvc、ajax等）好像没体现出大家风范，感觉很矬；
2、另一方面，我不相信这是微软的真正实力的表现，我从很多msdn帮助里都能体会到微软对软件开发的很多理解都是非常深刻和先进的，这也让我受益匪浅；
现在的实体类不都是基于数据表吗?
假如我有表User_Info 字段 User_ID,LGN_ID,User_Name,User_Age,Reg_Date
同时还有个关联的表 Login 字段 LGN_ID,LGN_Name,LGN_PWD,LGN_Date
那么就你就会有2个实体类 User_Info,Login 分别对应这2个表
现在你要关联查询 LGN_Name='zhansan的基本信息
那么我可以这么作，先在库里设计一个视图create view Partner
as
select User_ID,User_Name,User_Age,Reg_Date,b.LGN_ID,LGN_Name
from User_info a
inner join Login b on a.LGN_ID=b.LGN_ID这样，你就可以基于这个视图来设计实体类了
class Partner
{
int m_User_info=0;
string m_User_Name ="";
……
string m_LGN_Name =""; …… publice int User_ID{
set{m_User_ID = value;}
get{return m_User_ID;}
}
}
好了，别考虑分层了，直接写代码，再说一遍：
楼主花这些时间不如老老实实研读一些老外的OO基础书籍和UML书籍；你关心的知识必须在这些书籍和实践之间不断迭代之后得到，
没有速成的方法，
高手们最多给你理论方面的建议和指导，让你少走方向上的弯路。
好吧，也就是说 直接通过view层写访问数据库的代码？ 为了防止sql注入。使用@ 。或则是写个访问数据库的类，view层调用这个类的相应方法，实现数据查询。对吗？我试试。
希望我能获得些宝贵的东西。为以后研究三层架构。！！！
这就对了，数据库受控于模型，不仅如此，整个开发的大部分事务都受控于模型，
1、数据库是在交付最终项目的时候生成的，也就是项目迭代已经结束了；
2、程序copy连同模型副本一同发布，至此每个客户开始进化属于他们自己的应用程序；
3、发布以后的需求变更是要收费的，而变更仅仅通过修改模型即可完成；
如果你在某个业务领域拥有100个客户（不算多吧），而他们都有自己个性化的小小需求，
你是不是能满足这些需求并且顺便挣大把的服务费呢?
如果对某个查询、录入或者数据呈现有很多不同的要求，而且还会变化，我且不说你要怎么该项目，就是光维护不同的发布版本就够你受得了，赚钱就别指望了
提高你的设计思想
先看一个例子，我们假设系统中还存在一个实体类 Group，我们使用PDF.NET的OQL表达式写一个支持两个实体连接查询的语句：
OQL q=OQL.From(user)
.JoinIn(group) //连接Group实体
.On(user.GroupID=group.ID)
.Select(user.ID,user.Name,group.GroupName) //选取指定的字段下面就可以映射出两个实体集合了：
EntityContainer ec = new EntityContainer(q, db);
ec.Execute();
var mapUser1 = ec.Map<User>().ToList ();
var mapGroup1= ec.Map<Group>().ToList();
如果觉得这样分别使用两个实体对象集合（ user和group）比较麻烦，那么再自定义一个“用户机构”类即可：
class UserGroup
{
int ID{get;set;}
string Name{get;set;}
string GroupName{get;set;}
}
EntityContainer ec = new EntityContainer(q, db);
ec.Execute();
var mapEntity= ec.Map<UserGroup>((e) =>
{
e.GroupName = ec.GetItemValue<int>("GroupName");
e.ID = ec.GetItemValue<int>("ID");
e.Name = ec.GetItemValue<string>("name");//不区分大小写
return e;
}
).ToList ();
详细内容请看 打造轻量级的实体类数据容器
还以为是说SqlCommand.Parameters 这个才是防止SQL注入 不过也不是说删除 而是过滤一些注入字符 比如单引号和双引号都会被过滤成双份
对不起楼主了 不吃饭反思2天。。