Note that there are some explanatory texts on larger screens.

plurals
  1. PODo any .NET ORMs use constructors "properly"?
    text
    copied!<p>This is related conceptually to my question <a href="https://stackoverflow.com/questions/826872/orms-and-constructors">here</a>. However, I've been playing around with NHibernate, and realized what the real core of my question is. </p> <p>In classic OO design, to properly encapsulate data, it's a common pattern to have values passed in to an object's constructor that are stored in data members (fields). Those values which should <em>not</em> be changed are exposed with only accessors (read-only properties). Those which it is permissible to change have both accessors and mutators (read-write properties). It seems to me that a <strong>proper</strong> O/RM should respect these conventions, and use the available constructors when creating an object. Relying on read-write properties, reflection, or other, hackish (IMHO) methods seems...wrong.</p> <p>Is there a .NET O/RM solution out there that does this?</p> <p><strong>EDIT</strong></p> <p>To address Praveen's point, I know that there are projects that have a 'default' algorithm for choosing a constructor - StructureMap, for example, always uses the constructor with the most arguments, <em>unless</em> you mark a constructor with a custom attribute. I can see this being an effective way handle the situation. Perhaps utilizing an IoC container <em>in addition to</em> the ORM would provide the sort of solution I'm needing - though it seems to me that this is, while not inherently bad, an unnecessary additional step for using an ORM.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload