公开程序集外部的实体
我正在寻找有关将实体传递到程序集边界之外的最佳实践的意见。我正在使用 Linq-To-SQL，但同样的问题也适用于 Entity Framework、NHibernate 等。
我有一个程序集，我想在多个项目中重用。其中有几个实体到目前为止我一直保留在内部，但是我发现将实体列表返回给调用者是有益的。我应该创建一个新类来封装数据，还是应该公开实体本身。
例如，假设我有一个地址实体。拥有一个返回 Address 实体的方法 GetAddress(...) 会更好，还是应该创建另一个具有相同属性的类来公开 Address 数据？
谢谢！
I'm looking for opinions on best practices with regards to passing entities beyond assembly boundaries. I'm using Linq-To-SQL, but the same question would apply to Entity Framework, NHibernate, etc.
I have an assembly that I want to reuse in multiple projects. In it there are several entities which I have so far kept internal, however I am finding it would be beneficial to return a list of the entities to the caller. Should I create a new class to encapsulate the data or should I just expose the entity itself.
For example, let's say I have an Address entity. Would it be better to have a method GetAddress(...) that returns the Address entity, or should I create another class with the same properties to expose the Address data?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一票赞成只揭露实体。在实践中，将实体隐藏在 DTO 背后的原因最终并不真正相关。例如，您最后一次为完全不同的东西删除内部数据访问层是什么时候？这会导致您丢失自动生成的实体类？
此外，您还可以避免仅公开 DTO 时发生的痛苦映射工作，从而节省时间。 IMO，拥有一个使用反射或其他东西的自动映射工具并不算没有痛苦，因为现在你在性能上付出的代价是你本来会在单调乏味中付出的代价。
One vote for just exposing the entities. In practice, the reasons for hiding the entities behind DTOs end up not really being relevant. For example, when was the last time you ripped out your internal data access layer for something entirely different that would have caused you to lose the auto-generated entity classes?
Plus you get to save time by avoiding the painful mapping exercise that ensues when you only expose DTOs. IMO, having an automatic mapping tool that uses reflection or something doesn't count as no pain because now you pay in performance what you would otherwise pay in tedium.
您可能需要考虑使用存储库将实体公开给外部程序集。 这里是一篇关于可与 EF 一起使用的通用存储库的精彩 CodeProject 文章。
You might want to consider using a Repository to expose the Entities to outside assemblies. Here is a great CodeProject article on a generic Repository that can be used with EF.