Exposing Entities Outside The Assembly

Question

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!

Answer 1

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.

Answer 2

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.