c# - Linq to Sql 和关注点分离——我这样做对吗？

Question

我有一个正在使用 LINQ to SQL 进行的项目，并且我已经设置了要在我的 Web 应用程序中使用的业务对象/模型。我正在寻找一些关于我如何设置所有这些的反馈，看看它是否有意义，以及是否有什么我应该做的不同。

这是一个示例模型:

public class User
{
    private MyDataContext _db = new MyDataContext();
    private MyLINQUserClass _user = new MyLINQUserClass();

    public string Name
    {
        get
        {
             return _user.Name;
        }
        set
        {
             _user.Name = value;
        }
    }

    public User(int UserID)
    {
        _user = _db.Where(u => u.UserID == UserID).FirstOrDefault();
        if (_user == null)
        {
            _user = new MyLINQUserClass();
        }
    }

    internal User(MyLINQUserClass user, MyDataContext db)
    {
        _db = db;
        _user = user;
    }

    public void Save()
    {
        _db.SubmitChanges();
    }

    public static User Add(string Name)
    {
        MyDataContext _db = new MyDataContext();
        MyLINQUserClass _user = new MyLINQUserClass();

        _user.Name = Name;
        _db.MyLINQUserTable.InsertOnSubmit(_user);
        _db.SubmitChanges();

        return new User(_user, _db);
    }

    public static IList<User> Get()
    {
        MyDataContext _db = new MyDataContext();
        return _db.MyLINQUserTable.Select(u => new User(u, _db)).ToList();
    }
}

为清楚起见，我在项目中已经大量使用了这种类型的模型(以上只是我为动态发布而拼凑的示例)并且效果很好。我的问题更像是一个“学习”问题......我知道它有效。我只是不确定我是否应该做一些更好的事情，如果是的话，为什么。

想法？

Answer 1

我想这类问题没有正确的答案。这是设计、偏好和要求的问题。我将尝试展示我的观点...

我一直很喜欢 Repository pattern使关注点分开。我会使用类型 T 的存储库来检索 T 实体(谈论泛型)。这些将是参与我的商业模式的实体。在你的情况下，我会有一个 UsersRepository 类，返回 User 实体。此数据访问层 (DAL) 将处理我的数据访问问题。

我的业务模型将使用实体来开展业务。在简单的 CRUD 应用程序中，除了我的存储库返回的实体之外，可能不需要其他对象。在更复杂的应用程序中，将需要新类，使用 DAL 的存储库将数据作为实体检索。此业务层将处理我关注的主要业务功能(计算等)。

然后，出于显示目的，您可能需要另一种结构。例如，如果您关注 MVC pattern (您还可以看到 Microsoft article )您需要创建另一个模型来满足您的显示目的。这个遵循 MVC 模式的 GUI 层将处理我的图形显示问题。

希望我有所帮助!