使用 WCF 生成的类与创建自己的模型 dll 有何优缺点？
到目前为止，我的项目严重依赖链接到数据库的 WCF。 如果您愿意在我们的系统中进行处理，我们会使用从数据库生成的 ORM 类。
我知道使用 DataSvcUtil，我们可以轻松提取所有类并将其编译为 DLL，以便在我们的其他系统之间共享。
但在我们当前的项目中，我们创建了另一个 DLL，它镜像 WCF 生成的表类，而不是直接使用这些类。
- 所以我的问题是有关于这类事情的最佳实践吗？
- 和 这两种方法的优缺点是什么？
- 还有其他吗 方法？
谢谢
更新：
似乎共识是创建您自己的自定义类，而不是依赖于 WCF 创建的类。
我目前正在遵循这种方法，到目前为止，仅使用扩展来创建方法来转换为模型，并使用另一种方法将其转换回类型。
拥有自己的更简单的类对于可扩展性和其他东西很有好处:)
As of now, my project relies heavily on WCF which is linked to a database.
we use the classes generated from the database which are ORM if you will to do processing in our system.
i know that using DataSvcUtil, we can easily extract out all the classes and compile that as a DLL to be shared across our other systems.
But in our current project, we create another DLL which mirrors the WCF generated table class rather than using those classes directly.
- So my question is there a best practice on these sort of things?
- and
what's the pros and cons of these two methods? - are there other
methods?
thanks
Updates:
It seems like the consensus is on creating your own custom classes rather than relying on those that are created by WCF.
I am currently following this method, and as of now just using extension to create method to convert to the model and another one to convert it back to the type.
And having your own simpler class is good for extensibility and other stuff :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我建议仍然使用 WCF，但使用编译的 dll 作为客户端而不是服务引用。这样，即使您将来决定更改数据库，您仍然可以保持界面一致。使用 DLL 的优点：
使用 DLL 的缺点：
I would suggest to still use WCF, but use compilied dll as client instead of service reference. This way you can still have your interface consistent, even if you will decide to change database in future. The pros of using DLL:
Cons of using DLL:
我对 WCF 不太熟悉，但我使用 Linq To Sql，我假设它会生成相同类型的类（与任何 ORM 工具一样）。我总是创建自己的 POCO 类来描述我的域模型。我知道还涉及更多工作 - 然后您的任务是将 POCO 类与生成的类进行映射。但我发现这是保持域类纯净的最佳方法。生成的类可能有些复杂，其中包含描述将用于填充它们的表和列的属性。我喜欢生成的类，因为它们使我更容易与数据库交互——但我总是喜欢将简单的域类分开——它还使我能够灵活地交换数据库实现。
I'm not that familiar with WCF-- but I use Linq To Sql which I'm assuming generates the same types of classes (as does any ORM tool). I always create my own POCO classes which describe my domain model. I know there is a bit more work involved-- and you are then tasked with mapping your POCO classes with your generated classes. But I find it the best way to keep my domain classes pure. The generated classes can be somewhat complex with attributes describing the tables and columns which will be used to populate them. I like the generated classes because they make it easier for me to interact with the database-- but I always like the separation of having the simple domain classes-- it also gives me the flexibility to swap out database implementations.
最好像在当前项目中那样拥有一个单独的 dll - 解耦是最佳实践，从数据库生成 WCF DataContracts 几乎肯定不是一个好主意 - 它可以用于第一次拍摄，但后续更改您的数据库不应直接反映在 Web 服务中。
使用 WCF 的优点之一是，您可以轻松地通过服务层实现解耦，如果您要分发按照您描述的方式编译的 dll，那么您实际上会将所有客户端耦合到数据库表示形式。
解耦使您的 ORM/数据库能够根据需要进行调整，而无需所有客户端重新编译。
不利的一面是，像这样的解耦预先实施起来会有点慢，所以如果你有一个非常小的项目可能会有点过分，但如果你是跨团队工作或以任何方式分布式工作，那么它是必不可少的。
It is better to have a separate dll as you do in your current project - decoupling is a best practice, generating the WCF DataContracts from the database is almost certainly not a good idea however - it can be used for the first shot but subsequent changes to your database should not be directly reflected in the web service.
One of the advantages of using WCF is that you can easily achieve decoupling through a service layer, if you were to distribute a dll compiled in the way you describe you would essentially be coupling all clients to your database representation.
Decoupling enables your ORM / database to be tweaked as necesarry without all you clients having to re-compile.
On the con side - decoupling like this is a bit slower to implement up front - so if you have a very small project can be overkill - but if you are working cross team or in any way distributed then it is essential.