操作实体的类的名称
我有一个关于命名约定的一般性问题。
如果我将数据和操作分成两个单独的类。一个类拥有数据元素（实体），另一个类操作实体类。我们通常将操作实体类的类称为什么？
（我所指的实体与任何类型的实体框架无关）
经理？控制器？操作员？操纵者？
提前致谢
i have a general question regarding naming convention.
if I separate the data and operations into two separate classes. one has the data elements (entity), the other class manipulates the entity class. what do we usually call that class that manipulates the entity class?
(the entity I am referring to has nothing to do with any kind of entity framework)
manager? controller? operator? manipulator?
thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这取决于您对这些数据契约/实体执行什么类型的操作。以下是我的一些约定。让我们使用
Fruit实体的示例（我并不是试图暗示这些都是静态方法，只是伪代码）：FruitRepository.Save(水果项);InventoryManager.ShipFruit(Fruit[] 商品，字符串地址);FruitController.ShowDetails(stringfruitId);FruitProcessor.RemoveSeeds(Fruit[]很多Fruit);FruitManipulator.PeelFruit(水果项目);FruitProvider.GetAllTypesOfFruit();FruitProvider.IsInSeason(stringfruitName);FruitExporter.Save（字符串电子表格）；FruitAnalyzer.Weigh(Fruit[] items);FruitAssembler.Combine（字符串speciesFile，字符串数量File）;FruitFactory.CreateApple(); // 红色美味、麦金托什等FruitBuilder.AddSeeds(5); FruitBuilder.AddStem();这些都有些松散。主要目标是在您自己的代码库中保持一致，并避免与您正在使用的技术发生冲突 - 即。如果您正在使用 ASP.NET MVC，则不会有很多不是控制器的控制器类。
It depends on what kind of operations you're doing on those data contracts/entities. Here are some of my conventions. Let's use the example of a
Fruitentity (and I'm not trying to imply these are all static methods, just pseudocode):FruitRepository.Save(Fruit item);InventoryManager.ShipFruit(Fruit[] items, string address);FruitController.ShowDetails(string fruitId);FruitProcessor.RemoveSeeds(Fruit[] lotsOfFruit);FruitManipulator.PeelFruit(Fruit item);FruitProvider.GetAllTypesOfFruit();FruitProvider.IsInSeason(string fruitName);FruitExporter.Save(string spreadsheet);FruitAnalyzer.Weigh(Fruit[] items);FruitAssembler.Combine(string speciesFile, string quantitiesFile);FruitFactory.CreateApple(); // red delicious, McIntosh, etcFruitBuilder.AddSeeds(5); FruitBuilder.AddStem();These are all somewhat loose. The main goal is to stay consistent within your own codebase and avoid conflicts with the technologies you're using-- ie. don't have a lot of Controller classes that aren't controllers if you're doing ASP.NET MVC.
我通常和经理一起去。
I usually go with Manager.
无论您喜欢什么名称，只要确保在整个项目中一致使用该名称即可。我们拥有的最接近的东西是
Capability或Receiver但即便如此，这些也不完全是您所说的。然而。
您是否有将数据与方法分开的具体原因？除非你谈论一个类及其工厂，否则如果这种分离确实有必要，我会感到非常惊讶。
Call it whatever you are comfortable with, just make sure you use that name consistently throughout your project. The closest thing we have is a
Capabilityor aReceiverbut even then these aren't quite what you're talking about.However.
Do you have a specific reason for separating the data from the methods? Unless you talking about a class and its factory I'd be really surprised if this separation is truly warranted.
让我们进行如下推理：
如果逻辑使用仅一个实体，请将其移动到实体本身（请参阅富域模型与贫血域模型）。
因此，这些类中的大多数都实现了处理多个实体的逻辑，因此代表了协作。
此类类不应根据其职责来命名。诸如
manager、controller、manipulator等技术术语仍然可以用于命名约定，但重要的部分是第一部分名字。示例：
Let's reason like following:
If the logic uses only one entity, move it to the entity itself (See rich domain model vs. anemic domain model).
So most of these classes are those which implement logic which deal with more than one entity, hence represent a collaboration.
Such class should not be named according to their responsibility. A technical term such as
manager,controller,manipulator, etc. can still be use for naming convention, but the important part is first part of the name.Example:
不。这与面向对象设计背道而驰。
Don’t. This flies in the face of object-oriented design.