关于.NET中用户类设计时属性设置的问题
各位兄弟姐妹，大家好：
  小弟我正在用ASP.NET+C#做网站，但我技术是个二把刀（以前ASP转过来的），现在有个很小的疑惑，求解答。
  数据库中用户表包括UserID（用户ID）,UserName（用户名）,UserPWD（密码）,GroupID（用户所属组）,ItemID（用户所属项目）等字段,因此我设计了一个用户类(Class Users)，包含UserID,UserName,UserPWD,GroupID,ItemID等属性，还有一些方法，对用户的操作都在此进行。在用户详细信息等页面可以通过方法Public Users GetUserInfoByUserID(int UserID)来获取，不过除了需要上述信息外，还需要知道GroupID对应的GroupName,ItemID对应的ItemName。现在的问题：在用户类中，是不是要加入GroupName和ItemName属性，是上述方法可以一次返回所有需要的东西呢？如果不加，那么在上面的方法获得了用户信息后，还需要再去获取GroupName和ItemName信息（可以从数据库中查询或者通过另一个方法返回）；如果加了，是很方便，一个方法就够了，但是这两个属性总感觉并不是那么必要，好像是多于的，因为已经有GroupID和ItemID了。
  所以请教各位平时都是怎么做的，给我指点一下，谢谢！

------解决方案--------------------
看得出，您写asp一定是个高手。呵。

这个问题，我以前也很困惑。

假设加上，sql查询中，就要加上左、右或全链接等。那么返回的字段，就应该在类中进行添加，这样类的确多了两个属性。从性能上来说和网络流量上来说，的确带来了损失。

假设不加上，如果你将数据绑定到gridview这样的控件上时，发现又需要GroupName这样的信息，这时，你不得不调用另一个方法，再查一次数据库。你可能会在gridview的行绑定时的事件上加上，这样，10行的gridview就查了10次。。。
从这点上来看，还不如设计类时，就加上。。

这的确是个两难的选择。

不过，我一般是把所有需要的属性都加上。。

------解决方案--------------------
设计软件的人应该盯紧需求，而不是动不动都从关系数据表结构出发。

设计领域对象，实际上可能是这样：

public class User
{

public string UserID{get;set;}
public string Name{get;set;}
public string PWD{get;set;}
public Group Group{get;set;}
public Item Item{get;set;}

......
}

也就是说，既不是保存GroupName也不是保存GroupID，而是直接返回Group对象。当你获取一个User实例时，并不是立刻查询出所属Group，当你的程序调用Group属性的Get方法时才会去查询数据库。

至于说User在关系数据库中保存GroupID，则完全是一个隐藏在User内部的private属性，当对Group属性get/set时使用到它。如果你要得到Group的信息，你可以写：

User user=BLL.查询UserByID("sp1234");
Group group=user.Group;
string name=group.Name;
string id=group.ID;
DateTime ct=group.CreateDateTime;

对于Item的设计，也是一样的面向对象地设计其接口协议，而不是在User中出现ItemID这种东西。