6

我很难围绕业务对象或更具体地说是业务对象集合。

这是我正在尝试做的一个简单示例。

如果我有一个事件对象，则该对象可能涉及许多人，并且每个人对象都可以有多个注释。没有 Person 对象，Notes 就不能存在，而如果没有 Incident 对象，Person 对象就不能存在。

如果我有 Public List<Note> notes = new List<Note>() 那么 ADD 和 REMOVE 等方法对事件中的人员可用。我假设如果我要在 Notes 集合上调用这些方法，它只会将其从列表中删除，但不会执行任何代码来实际从数据源中添加/更新/删除员工。这让我相信我不应该使用 List 而是其他东西？

这也引出了我另一个问题。实际的数据库CRUD操作应该驻留在哪里。Note 对象应该有自己的 CRUD 还是应该由 Person 对象负责，因为没有它就无法存在？

我对走哪条路有点迷茫，我想把这部分做好，因为它将成为程序其余部分的模板。

4

3 回答 3

1

已经提供了一些重要的信息，但您提到的一件事可能会让您感到困惑：

“如果我有 Public List notes = new List()，那么 ADD、REMOVE 等方法对事件中的人员可用。”

这一切都取决于你如何设计你的课程。您应该考虑的一件事是这些数据相互关联的方式。这将帮助你描绘你的班级设计。

听起来像下面这样：

  • 一个事件可能涉及许多人
  • 一个人可以创建多个笔记
  • 注释是最低级别，并且由于正在创建事件和负责该事件的负责人而存在。

事件 1 - 许多人

人 1 - 许多笔记

您可以通过多种方式建立这种类型的关系。一种方法可能是实际分离所涉及的对象，然后创建连接的对象。

例如

public class Incident {
//insert incident fields here
//do not add person logic / notes logic
//probably contains only properties
}

public class Person {
//insert person fields
//private members with public properties
//do not embed any other logic
}

public class Comment {
 //insert comment private fields
 //add public properties
 //follow the law of demeter
}

这些类不会相互提供详细信息，它们只是存储这些信息的存储库。然后，您可以将这些类相互关联，例如

public class IncidentPersonnel {
List<Person> p;
//add methods to add a person to an incident
//add methods to remove a person from an incident
....
}

然后你可能有另一个班级处理人员的评论

public class PersonnelNotes {
List<Note> n;
//other methods...
}

你可以更进一步，但这可能会使事情复杂化，但我只是给你另一个关于如何处理这个问题的想法。

尽量遵循得墨忒耳定律

封装你所有的对象，此外，你的邻居可以和你说话，但其他的不多……这将有助于保持你的类松散耦合，并使你的思考过程更简单。

最后，您提到了 CRUD 操作应该如何工作。这一切都可以追溯到您的DAL（数据访问层）。与其从表中返回数据行，不如返回一个引用对象及其所有属性。添加和删​​除的工作方式相同（传入或传出对象）。您可以使用 ORM 或编写自己的 DAL。这完全取决于您希望自己参与的程度:)。

于 2010-01-20T13:47:52.960 回答
1

你在这里有几个不同的问题，我会尽量回答。

关于使用问题List<T>- 该框架ReadOnlyCollection<T>在您的情况下非常有用。这是一个一旦创建就不允许添加或删除的集合。

关于 CRUD 操作责任 - 这应该属于您的数据层，而不是您的任何对象（请参阅SRP - 单一责任原则）。

于 2010-01-20T13:27:24.813 回答
1

我这样做的方式是：每个具有子对象的对象都包含它们的列表，每个具有父对象的对象都包含一个具有其类型的属性。添加是通过填充对象（或对象层次结构）并在需要时发送到 DAL 以进行持久性来完成的。CRUD 操作都在 DAL 中，它与对象类型无关，但使用这些类型来确定要访问哪些表、列等。删除是唯一通过设置触发 DAL 将其删除的对象的 Deleted 属性以不同方式处理的事情。

现在关于业务逻辑 - 它不与对象本身（DAO）一起存在，而是由在必要时接收或收集此类 DAO、执行其工作并将 DAO 发送回 DAL 以进行更新的类完成。

于 2010-01-20T13:29:56.823 回答