我应该将生成的类隐藏在层后面吗？
我有几个从 WSDL 生成的类，我需要编写 2 个小型应用程序来读取一些输入数据、调用 Web 服务并写入响应。
现在，我创建了一堆非常简单的包装类，它们从 Web 服务调用返回的对象中获取数据。我创建了一个围绕 Web 服务代理的包装器，它返回我自己的类而不是生成的类型。我试图实现的目标是一个解耦模型，它不会向我的简单应用程序透露任何生成的类。
但我认为我可能会过度设计整个事情。目前，这两个小型应用程序的大小几乎与模型类和包装器相同，但我确信稍后会出现更多要求，并且我希望保持灵活性。
我应该隐藏生成的类（并将这部分视为数据访问层）还是应该使用第一个版本的生成类？
I have several classes that were generated from a WSDL and I need to write 2 small applications that read some input data, call the webservice and write the responses.
Right now I created a bunch of very simple wrapper classes that take the data from the objects returned by the webservice call. I created a wrapper around the webservice proxy that returns my own classes instead of the generated types. What I try to aim for is a decoupled model, that will not reveal any of the generated classes to my simple applications.
But I think I may overengineer the whole thing. For now the 2 small applications will be almost the same size as the model classes and wrappers, but I am sure there will be more requirements coming up later and I want to be flexible.
Should I hide the generated classes (and think about this part as a Data Access Layer) or should I go with the generated classes for the first version?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们在这里谈论将军，所以我会以同样的方式回应。除非您有特定的构建要求，否则不要为未来进行过多的设计，除了选择可以灵活应对未来的框架和方法之外。问题是，如果你现在就为未来进行设计，你甚至没有明确的要求，所以你只能靠猜测和担忧。请参阅“你不会需要它”原则。
现在，关于您现在是否需要数据访问层的问题：如果您发现有一个层除了在其他两个层之间进行转换之外什么也不做，那么您就不需要它。另一方面，如果有一组任务在一个层中处理，这将使其他层更加简洁和清晰，希望同时减少冗余，那就去做吧。
We are talking in generals here, so I will respond in kind. Unless you have specific requirements that you are building to, don't engineer for the future too much, other than choosing frameworks and methodologies that can be flexible for the future. The thing is, if you engineer for the future now, you don't even have the requirements nailed down so you are working on guesses and worries. See the "You Ain't Going to Need It" principle.
Now for the question of wether you need the Data Access Layer now: if you find that you have a layer that does nothing but translate between two other layers, you don't need it. If, on the other hand, there are a set of tasks that if handled in a layer that will make other layers more concise and clear, hopefully all while reducing redundancy, go for it.