ORMs and Constructors

Question

I'm looking over .NET ORM implementations, and I have a major burning question - are there any .NET ORM implemenations that don't require public properties for every field in the database? When I see examples like this, a little bell goes off in my head. I firmly believe in encapsulation, and being forced to open the kimono of my objects just to make them work nicely with persistence frameworks gives me the heebie-jeebies. Is this sort of accessibility required in all ORMs out there? If not, please point me to examples of those that don't need it!

Answer 1

Check out Scott Gu's nerd dinner tutorial. LINQ and MVC lets you create a business layer that wraps the DB objects in public and private properties.

http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx

Answer 2

You mean you would like to map private or protected members to the database, rather than having them all public? One ORM I have used that can do that is Gentle.NET. It is stable but not really getting many updates these days.

Answer 3

NHibernate supports mutiple access strategies for class members. Public properties are a de-facto default but you can tell NHibernate to access the fields of your class directly.

e.g.

<property name="CustomerName" access="field.camelcase-underscore" />

will instruct NHibernate to use a field in your class declared like this:

protected string _customerName;

Answer 4

The Entity Framework supports that, too. You can define the access modifier per property and independently for the getter and the setter.

Answer 5

Mindscape LightSpeed binds only to fields - only add properties for fields you wish to expose (this is the only way it works for the express reason of encapsulation). Of course the tooling will default to providing properties but it can all be turned off.

Mindscape LightSpeed O/R Mapper

Answer 6

LINQ to SQL can bind to private fields but it does not however fully support a private parameterless constructor.

Answer 7

Harper - I felt pretty much the same way about Linq-To-SQL until I realized that it's all about how you think about the ORM... it helps to think of Linq2SQL as nothing more than a "strongly typed ADO.NET provider"...

If you just want a "quick look" at a couple of fields, then LINQ projections will return anonymous types to you that only contain the fields you're interrested in. This means that the size of the entity class is irrelevant to the network and memory performance of youre query.

On the far other side of the spectrum, DataContexts (or UnitOfWork in other ORMs) are typically something that you use and dispose of as quickly as possible. It follows, then, that the entities they generate should be limited in their role to merely being "data holders". Put differently, if you want to construct complex or long living objects, design them seperately from the LINQ entities (i.e. different classes), and just use L2S to populate/instansiate those objects.