我应该如何设计我的对象模型，以便我的 DAL 可以填充只读字段？

Question

为了分离关注点，在我当前的项目中，我决定将我的 DAL 和 BLL/Business 对象完全分离到单独的程序集中。我想将我的业务对象保持为简单的结构，没有任何逻辑，以使事情变得非常简单。我希望我也可以将我的业务逻辑与我的 DAL 分开。所以我的应用程序会告诉我的 DAL 加载我的对象，我的 DAL 将运行到数据库并获取数据，用数据填充对象，然后将其传递回我的 BLL。

问题 - 我如何将我的 DAL 放在单独的程序集中并将数据推送到只读字段中？

• 如果我将 getter 设置为受保护，那么继承的对象可以访问它，这不是我真正想要的，因为我将返回继承的对象类型，而不是原始对象类型。
• 如果我将 getter 设置为内部，那么我的 DAL 必须与我不想要的 BLL 驻留在同一个程序集中。
• 如果我将 getter 设置为 public，那么任何人都可以在它应该是只读的时候读/写它。

编辑：我注意到我可以有一个 ObjectBase 的返回类型，但实际上是从 ObjectBase 派生的一个对象或对象集合返回给外部世界（在我的 DAL 之外）属性将是只读的，但我的派生类型（只能在我的 DAL 中访问）属性实际上是读/写的。

Answer 1

您可以通过构造函数设置只读属性。

Answer 2

这是没有灵丹妙药的情况；最简单的选项受到限制或无法满足您的要求，而彻底的解决方案要么开始有异味，要么开始偏离简单。

也许最简单的选项是我在这里没有提到的：保持字段/属性私有并将它们作为 out / ByRef 参数传递给 DAL。虽然它不适用于大量字段，但对于少量字段来说很简单。

（我没有测试过，但我认为值得探索）。

public class MyObject()
{
    private int _Id;
    public int Id { get { return _Id; } } // Read-only

    public string Name { get; set; }

    // This method is essentially a more descriptive constructor, using the repository pattern for seperation of Domain and Persistance
    public static MyObject GetObjectFromRepo(IRepository repo)
    {
        MyObject result = new MyObject();
        return repo.BuildObject(result, out _Id);            
    }
}

public class MyRepo : IRepository
{
    public MyObject BuildObject(MyObject objectShell, out int id)
    {
        string objectName;
        int objectId;

        // Retrieve the Name and Value properties
        objectName = "Name from Database";
        objectId = 42;
        //

        objectShell.Name = objectName;
        Console.WriteLine(objectShell.Id); // <-- 0, as it hasn't been set yet
        id = objectId; // Setting this out parameter indirectly updates the value in the resulting object
        Console.WriteLine(objectShell.Id); // <-- Should now be 42
    }
}

---

还值得注意的是，尝试将您的域/业务对象保持在最低限度可能比您想象的要多。如果您打算对它们进行数据绑定，那么您需要实现 IPropertyNotifyChanged，这会阻止您使用自动实现的属性。您应该能够保持它相当干净，但您必须为基本功能做出一些牺牲。

Answer 3

这可以很好地保持您的 SoC 模型，不会增加太多复杂性，它会阻止写入只读字段，并且您可以使用非常相似的模型来解决序列化问题。您的 DAL 仍然可以写入您的只读字段，如果以类似方式使用您的序列化程序也可以写入 - 这意味着开发人员必须有意识地写入只读字段以防止无意误用。

模型项目

namespace Model
{
    public class DataObject
    {
        public int id { get; protected set; }
        public string name { get; set; }
    }   
}

数据项目

namespace Data
{
    class DALDataObject : DataObject
    {
        public DALDataObject(int id, string name)
        {
            this.id = id;
            this.name = name;
        }
    }
    public class Connector
    {
        public static DataObject LoadDataObject(int objectId)
        {
            return new DALDataObject(objectId, string.Format("Dummy object {0}", objectId));
        }
        public static IEnumerable<DataObject> LoadDataObjects(int startRange, int endRange)
        {
            var list = new List<DataObject>();
            for (var i = startRange; i < endRange; i++)
                list.Add(new DALDataObject(i, string.Format("Dummy object {0}", i)));

            return list;
        }
    }
}

Answer 4

忍受它怎么样？

按照这些准则实施，但不要在模型中添加这样的硬约束。假设你这样做了，但随后又出现了另一个需要序列化它或做其他事情的请求，然后你就被它捆绑了。

正如你在其他评论中所说，你想要可互换的部分......所以，基本上你不想要与特定关系相关的东西。

---

更新 1： 或许“只是忍受它”过于简单，但我仍然必须强调，您不应该对这些事情过于深入。使用简单的指导方针，保持你的代码干净和可靠，这是你一开始可以做的最好的事情。它不会妨碍进度，而当一切都更稳定时重构并不难。

别搞错了，我根本不是一个不考虑就写代码的人。但是，我采用了这样的方法，并且只有在少数情况下它们会得到回报——没有任何迹象表明你不会通过简单和进化得到类似的结果。

恕我直言，这不适合需要在一开始就解决的重要架构问题。

先发制人的跟进：如果您不能信任您的团队遵循简单的指导方针，请当心。还要确保从一些结构开始，选择几个场景，用真实的东西设置结构，当有一些简单的东西时，团队会更好地了解他们的方式。

Answer 5

在我看来，处理此问题的最佳方法是让业务对象和 DAL 在同一个程序集中，并由命名空间分隔。这在逻辑上分离了关注点，并允许您使用内部设置器。我想不出将它们分成自己的程序集有什么好处，因为一个没有另一个是无用的。