对这里的一点乱弹兼提问题。

请恕我乱弹，放这里不合适的话，我立即撤走。

每当看到团队里的很多文章，我都会很佩服作者的内功和文笔，深感惭愧之极。但是我很少去仔细的阅读它们。我对模式有一些了解，但不熟练，不能很好的使用，而不少文章也只能提供比较理论的东西，即使随文附上例子，却仍然觉得有点隔靴挠痒，实际中还会有不少的困惑，并找不到比较好的方法来解决，所以不爽。

经常抱书来温故，收获有时还真不少。

但我觉得大家平时定有不少经验积累，比如对某些比较好的系统架构理解比较透彻，不妨列举它并加以分析，好在哪里，为什么这么设计，这样总比写文章并在文章里列举一个例子来得更直接。更一针见血。

 

提一个工作中的疑问，一直以来都不是很肯定，可能放这里不太合适，但借个宝地嘛。

 

    public class User
        {
            private string userID;
            private string name;
            private Department department;

            public string UserID
            {
                get{ return userID; }
                set{ userID = value; }
            }
            public string Name
            {
                get{ return name; }
                set{ name = value; }
            }

            public Department Department
            {
                //
            }

        }

        public class Department
        {
            private string deptID;
            private string name;

            public string DeptID
            {
                get{ return deptID; }
                set{ detpID = value; }
            }
        }

 

现在要显示User.UserID,User.Name,User.Department.DeptID,User.Department.Name,那么获取User.Department的数据是怎么获得？是先根据一个UserID获得一个User,然后呢？User中的Department数据怎么获得？还是直接通过Sql Inner Join 查出？（应该不是这样）如何设计这一层（数据逻辑层）？你们是怎么处理这一关系的？