我应该将更新方法封装在对象内部还是拥有接受要更新的对象的方法？
我实际上有两个彼此相关的问题：
我有一个名为 MyClass 的对象（类），它保存来自我的数据库的数据。目前，我有这些对象的列表（ List < MyClass > ），它们驻留在“公共区域”的单例中。我觉得以这种方式管理数据更容易，而且我不明白从一个对象到另一个对象传递一个类比单例有什么好处（如果有人能告诉我原因，我会很高兴）。无论如何，数据库中的数据可能会从程序外部更改，因此我必须经常更新数据。为了更新 MyClass 的列表，我有一个名为 Update 的方法，该方法是在另一个接受 MyClass 列表的类中编写的。这会更新列表中 MyClass 的所有实例。
但是，将 Update() 方法封装在 MyClass 对象内会更好，所以我会说：
foreach(MyClassList 中的 MyClass obj) { obj.update(); }什么是更好的实现？为什么？
更新方法需要 XML 读取器。我编写了一个 XML 读取器类，它基本上是该语言本机提供的标准 XML 读取器的包装器，它提供了应用程序特定的数据收集。如果 XML 读取器类无论如何都位于 MyClass 对象的“继承路径”中 - MyClass 对象继承自 XML 读取器，因为它使用了一些方法。我不明白为什么应该这样做。我不喜欢在 MyClass 内部声明 XML Reader 类的实例的想法，而 MyClass 对象意味着数据库中的一个简单“记录”，我觉得给它提供大量方法，其他对象实例有点凌乱的。也许我的 XML 阅读器类应该是静态的，但 C# 的本机 XMLReader 不是静态的？
如有任何意见，我们将不胜感激。
I actually have 2 questions related to each other:
I have an object (class) called, say MyClass which holds data from my database. Currently I have a list of these objects ( List < MyClass > ) that resides in a singleton in a "communal area". I feel it's easier to manage the data this way and I fail to see how passing a class around from object to object is beneficial over a singleton (I would be happy if someone can tell me why). Anyway, the data may change in the database from outside my program and so I have to update the data every so often. To update the list of the MyClass I have a method called say, Update, written in another class which accepts a list of MyClass. This updates all the instances of MyClass in the list.
However would it be better instead to encapulate the Update() method inside the MyClass object, so instead I would say:
foreach(MyClass obj in MyClassList) { obj.update(); }What is a better implementation and why?
The update method requires a XML reader. I have written an XML reader class which is basically a wrapper over the standard XML reader the language natively provides which provides application specific data collection. Should the XML reader class be in anyway in the "inheritance path" of the MyClass object - the MyClass objects inherits from the XML reader because it uses a few methods. I can't see why it should. I don't like the idea of declaring an instance of the XML Reader class inside of MyClass and an MyClass object is meant to be a simple "record" from the database and I feel giving it loads of methods, other object instances is a bit messy. Perhaps my XML reader class should be static but C#'s native XMLReader isn't static?
Any comments would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于你的第一个问题，我建议在 MyClass 中添加一个更新方法。听起来您可能正在实例化同一对象的多个副本，也许更好的解决方案是直接通过原始 MyClass 对象的更新方法来更新它们。
这也将为您带来额外的优势，即将来能够更新单个对象，并且应该更易于维护。
对于第二个问题，听起来 MyClass 包含来自数据库的数据，使其成为实体对象。实体对象不应包含业务逻辑，因此我认为让 Service 类使用 XMLReader 对数据执行操作，然后使用 getter/setter 来操作对象中的数据是可以的。与以前一样，这样做的优点是使代码保持松散耦合且更易于维护。
For your first question, I would suggest putting an update method in MyClass. It sounds like you may be instantiating multiple copies of the same object, and perhaps a better solution would be to update the original MyClass objects directly through their update methods.
This would also give you the added advantage of being able to update individual objects in the future and should be more maintainable.
For your second question, it sounds like MyClass contains data from a database, making it an entity object. Entity objects shouldn't contain business logic, so I think you'd be okay having a Service class use the XMLReader to perform operations on the data and then use the getters/setters to manipulate the data in the object. Same as before, this has the advantage of keeping your code loosely coupled and more maintainable.
不要在类中包含 Update()。我知道这看起来很诱人，因为更新调用“更容易”，但这会创建依赖项。 （大概）MyClass 包含数据库数据，因为它是一个域对象，代表某些现实世界“单元”的状态（有形的、概念性的或其他）。如果包含 update() 方法；现在，域对象不仅负责表示某些逻辑“事物”的状态，而且还负责持久性逻辑（保存、加载、新建、删除）。您最好创建一个处理这些职责的服务。这涉及到高内聚的设计原则，即。每个类只有 1 个职责（或者至少是一种职责）。例如.... persistenceService.saveUser(myUser);
这基本上是同一个问题，只不过现在您正在谈论使您的类直接依赖于特定类型的持久性（在本例中作为后代）（写入 xml 文件），这比让您的类成为更糟糕的以更通用的方式依赖于持久性。
当尝试做出设计决策时，可以这样想……计划变更（不稳定、混乱或任何你想称之为的东西）。如果一个月后您需要切换数据库的 XML 持久性怎么办？或者如果您突然必须处理 MyClassVariantA、MyClassVariantB、MyClassVariantC 该怎么办？通过最大限度地减少依赖关系，当您确实必须更改某些内容时，无需在应用程序的所有其他部分进行一系列更改。
Do not include Update() within the class. I know it seems tempting because it the update call "easier" but what that would be creating dependencies. (Presumably) MyClass contains db data because it is a domain object which is represents the state of some real world "unit" (tangible, conceptual, or otherwise). If you include an update() method; now you're domain object is not only responsible for representing the state of some logical "thing", but it is also responsible for persistence logic (save, load, new, delete). You'd be better off creating a service which handles those responsibilities. This relates to the design principle of high cohesion, ie. each class has only 1 responsibility (or type of responsibility at least). eg.... persistenceService.saveUser(myUser);
This is basically the same question, except now you are talking about making your class directly dependant (as a descendant in this case) of a specific type of persistence (writing to xml file) which is even worse than having your class be dependent on persistence in a more generalized way.
Think about it like this when trying to make design decisions... plan on change (instability, chaos, or whatever you would like to call it). What if a month from now you need to switch out the XML persistance for a database? Or what if you all of a sudden have to deal with MyClassVariantA, MyClassVariantB, MyClassVariantC? By minimizing dependencies, when you do have to change something it won't necessitate a cascade of changes throughout every other part of your application.