我很难绕过业务对象或更具体地说是业务对象集合。
以下是我正在尝试做的一个简单示例。
如果我有一个事件对象,则此对象可以包含许多人,并且每个Person对象都可以有多个注释。没有Person对象,Notes不能存在,如果没有Incident对象,Person对象就不能存在。
如果我有公开列表< Note> notes = new List< Note>()然后,事件中的Person可以使用ADD和REMOVE等方法。我假设如果我要在Notes集合上调用这些方法,它将只是从列表中删除它,但不执行任何代码来实际添加/更新/删除数据源中的员工。这让我相信我不应该使用List而是使用其他东西吗?
这也引出了另一个问题。实际数据库CRUD操作应驻留在何处。 Note对象是否应该有自己的CRUD,或者Person对象应该对它负责,因为它没有它就不存在?
我对于要走哪条路有点迷茫,我想让这一部分正确,因为它将成为该计划其余部分的模板。
答案 0 :(得分:1)
你在这里有几个不同的问题,我会尽量回答。
关于使用List<T>
的问题 - 框架有ReadOnlyCollection<T>
,在您的情况下非常有用。这是一个不允许在创建后添加或删除的集合。
关于CRUD操作责任 - 应该属于您的数据层,而不是您的任何对象(参见SRP - 单一责任原则)。
答案 1 :(得分:1)
我这样做的方法是:每个具有子对象的对象都包含它们的列表,每个具有父对象的对象都包含一个具有其类型的属性。如果需要,通过填充对象(或对象的层次结构)并发送到DAL以进行持久化来完成添加。 CRUD操作都在DAL中,它与对象类型无关,但使用这些类型来确定要访问的表,列等。通过设置对象的Deleted属性来触发DAL将其删除,删除是唯一不同的处理方式。
现在关于业务逻辑 - 它不驻留在对象本身(DAO)中,而是由在必要时接收或收集此类DAO的类完成,执行其工作并发送DAO返回DAL进行更新。
答案 2 :(得分:1)
已经提供了一些很好的信息,但是你提到的一件可能令你感到困惑的是:
“如果我有Public List notes = new List()然后是ADD之类的方法, REMOVE可供Person使用 在事件中。“
这一切都取决于你如何设计你的课程。您应该考虑的一件事是这些数据彼此之间的关系。这将帮助您描绘您的课堂设计。
听起来如下:
事件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...
}
你可以更进一步,但它可能会使事情复杂化,但我只是想让你知道如何处理这个问题。
尝试关注the law of demeter for functions
封装你的所有对象,此外,你的邻居可以与你交谈,但没有其他...这将有助于保持你的课程松散耦合,使思考过程对你来说更简单。
最后,您提到了CRUD操作应该如何工作。这一切都可以追溯到您的DAL(数据访问层)。而不是从表中返回数据行,然后您可以返回具有其所有属性的引用对象。以相同的方式添加和删除工作(传入或传出对象)。您可以使用ORM或编写自己的DAL。这一切都取决于你想让自己参与的程度:)。