使用实体转换器的 .NET 服务负担
我们在 .NET 和 WCF 应用程序中维护 EntityTranslator 以将业务消息转换为服务消息以及将服务消息转换为业务消息，这会增加负担。事实上，我不能将它们称为业务对象，因为我们只需要从数据库中获取并更新它们。我们从设备读取数据并存储到数据库，然后从数据库读取数据并存储到设备。
我们所有的类都是简单、普通的 .NET 类，并且不执行任何特定操作。
这是非常相似的课程。
这是我的服务实体。
[DataContract]
public class LogInfoServiceEntity
{
string data1;
string name;
}
public class LogInfo
{
string data1;
string name;
}
现在我需要定义翻译器来创建另一端的实例类型并复制另一端的数据。我们大约有 25 个这样的班级，我们觉得管理它们非常困难。因此，我们有 25 名企业对服务翻译员和 25 名服务对商业翻译员。
我喜欢使用简单的 POJO 类来存储和获取信息，而不是使用所有翻译器。
处理这种情况的最佳方法是什么？ 或者 翻译是处理这种情况的最佳方法吗？
We have incremental burden of maintaining EntityTranslator to transform the business messages to the service message and service message to business message in .NET and WCF application. In fact, I cannot call them as Business object since we just need to fetch from DB and update the same. We read data from device and store to DB and read data from DB and store to device.
All our classes are simple, plain .NET classes and doesn't do anything specific.
It is very similar classes.
Here is my service entity.
[DataContract]
public class LogInfoServiceEntity
{
string data1;
string name;
}
public class LogInfo
{
string data1;
string name;
}
Now I need to define the translator just to create the instance type of other side and copy the data other side. We have around 25 classes like this and we feel, very difficult to manage them. So we have 25 Business to Service translator and 25 Service to Business Translator.
I like to have simple POJO kind of classes to store and get the information than using all the translator.
What is the best way to handle the situation?
Or
Is translator is the best way to handle the situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Automapper 可能就是您要找的。
Automapper might be what you're looking for.
答案是“这取决于”。这完全取决于系统的复杂性。通常，WCF 服务接口应该是粗粒度的，并且不一定一对一映射到业务层实体，以防止与服务器的额外往返。
例如，WCF接口中的Customer实体可以传达更多的信息，甚至与业务层中的Customer实体不直接相关。但您另外返回此信息是因为您预测在 85% 的情况下，客户不仅需要客户数据，还需要在接下来的几分钟内所有订单/活动或任何其他补充信息。
这是通常的权衡——是返回更多还是更少。
在您的特定情况下，我会坚持使用代码生成：您始终可以编写一个工具来从业务逻辑实体中生成所有外部接口和转换器。
The answer is "it depends". It solely depends on the complexity of your system. Usually WCF service interfaces should be coarse grained and not necessarily map one-to-one to your business layer entities to prevent additional round-trips to server.
For instance, Customer entity in WCF interface can convey much more information, even not related directly to Customer entity in business layer. But you return this information additionally because you predict that in 85% of situations client will not only need Customer data, but also all orders/activities or any other supplementary information within next several minutes.
This is usual trade-off - whether to return more or less.
In your particular case I would stick with code generation: you can always write a tool which will generate all external interfaces and translators out of business logic entities.
这可能是一个愚蠢的问题，但是你为什么不呢？
通常，您会将合同分开，这样您就可以在不影响数据合同的情况下更改业务对象，但是将它们分开会给您带来什么好处呢？
This may be a daft question, however why don't you
Normally you keep your contracts separate so you can change your business objects without effecting your data contracts, however what benefit do you get from keeping them separate?