C# 业务对象和集合

发布于 2024-08-18 16:25:08 字数 579 浏览 3 评论 0原文

我很难理解业务对象,或更具体地说,业务对象集合。

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

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

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

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

我有点迷失方向,我想把这部分做好,因为它将成为程序其余部分的模板。

I'm having difficulty wrapping my head around business objects or more specifically, business object collections.

Here's a quick example of what I'm trying to do.

If I have an Incident Object, this object can have a number of people involved and each of those Person objects can have multiple notes. Notes can't exist without a Person object and Person objects can't exist without an Incident Object.

If I have Public List<Note> notes = new List<Note>() then methods such as ADD and REMOVE become available to Person within Incident. I assume that if I was to call those methods on the Notes collection it will simply remove it from the List but not execute any code to actually add/update/delete the employee from the data source. This leads me to believe that I shouldn't use List but something else?

This also leads me to another question. Where should the actual database CRUD operations reside. Should a Note object have its own CRUD or should the Person object be responsible for it since it can't exist without it?

I'm a little lost about which way to go and I'd like to get this part right because it will be the template for the rest of the program.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

公布 2024-08-25 16:25:08

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

“如果我有公共列表注释=新
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。这完全取决于您想要自己参与的程度:)。

Some great information has been given but one thing that you mentioned that may be confusing you is this:

"If i have Public List notes = new
List() then methods such as ADD,
REMOVE become available to Person
within Incident."

That all depends on how you design your classes. One thing that you should think about is the way this data relates to one another. That will help you picture your class design.

It sounds like the following:

  • One incident can involve many people
  • One person can create many notes
  • A note is the lowest level and exists due to an incident being created and a responsible person(s) working on that incident.

Incident 1 - many Persons

Person 1 - many notes

You can do this type of relationship in a number of ways. One way may be to actually seperate the objects involved, and then create joined objects.

For instance

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
}

These classes do not give details to one another, they are just repositories to store this information. You then relate these classes to one another for instance

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

Then you may have another class handling the commenting by personnel

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

You can go further with this but it may complicate things but I am just giving you another idea of how to handle this.

Try to follow the law of demeter for functions

Encapsulate all of your objects, in addition, your neighbor can talk to you but not much else... This will help keep your classes loosely coupled and makes the thought process a bit simpler for you.

Finally, you mentiond how the CRUD operations should work. This all goes back to your DAL (Data Access Layer). Rather then return rows of data from a table you could then return a referenced object with all of its attributes. Add's and remove's work the same way (passing in or out an object). You can use an ORM or write up your own DAL. It all depends on how involved you want to involve yourself :).

浅笑依然 2024-08-25 16:25:08

您在这里有几个不同的问题,我会尽力回答大部分。

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

关于 CRUD 操作责任 - 应该属于您的数据层,而不是您的任何对象(请参阅 SRP< /a> - 单一职责原则)。

You have several different questions in one here, I will try to answer most.

In regards to problems using List<T> - the framework has a ReadOnlyCollection<T> that is useful in exactly your situation. This is a collection that does not allow adding or removing once created.

In regards to CRUD operation responsibility - that should belong to your data layer, not any of your objects (see SRP - Single Responsibility Principle).

北凤男飞 2024-08-25 16:25:08

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

现在关于业务逻辑 - 它并不驻留在对象本身(DAO)中,而是由在必要时接收或收集此类 DAO、执行其工作并将 DAO 发送回的类来完成。 DAL 用于更新。

The way I do it is: each object that has children objects contains a list of them, and each object with a parent contains a property with its type. Adding is done by populating an object (or an hierarchy of objects) and sending to the DAL for persistence if desired. The CRUD operations are all in the DAL, which is agnostic of the object types but uses such types to determine which tables, columns, etc to access. Deleting is the only thing dealt with differently by setting an object's Deleted property which triggers the DAL to remove it.

Now regarding business logic - it does not reside with the objects themselves (the DAOs) but rather it is done by classes that receive or gather such DAOs when necessary, perform their work and send the DAOs back to the DAL for updates.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文