no, if you have a one-to-many collection of say, Person objects where Persons can be either Customers or Employees or whatever, the collection you’ve used will not contain proxies of these instances… they will just be instances of the type they represent. The collection however, is the one that enables the lazy-loading in this case. Access the collection and it will retrieve the data if it’s not there yet, but the retrieved objects themselves will not be proxies (though their many-to-one properties will be proxy instances if lazy-loading isn’t disabled for those associations)

1: Using proxies requires me to make my properties virtual, this makes me cringe! I only expose state when I need to, to make them virtual too makes me feel so dirty, and not the good kind of dirty.

2: I read (NHibernate in Action I believe) that when you have a multi association and the instances are really a mixture of base class instances and descendant instances the proxy approach will create a proxy of the base class for every entry. That CAN’T be right, can it?

http://elegantcode.com/2008/09/26/properties-a-false-sense-of-encapsulation/

“Who determines what data is required for an entity?”

there is at least some minimum defined in your dabatase (if you use one), and those are the ones you might as well put in your constructor. No matter what the “business” says, as long as they are required in the database i’d prefer to put those in the constructor. If they really aren’t required anymore you can just lift the not-null restriction in the database and get rid of the argument in the constructor.

Until that off the wall requirement is introduced (_if_ it happens), i’d prefer protection against non-nullable database columns over a hypothetical flexibility that i might never need. And once that off the wall requirement comes along, i’d consider getting rid of the not-null constraint.

I have this discussion often with devs I work with. “without too much trouble you can make sure that your entities always have their required data”. Who determines what data is required for an entity? The answer should be “the business”. Why enforce that at the entity level? Let the consumer of the entity assert whether or not the information is valid. Or delegate the validation to some business rules validator. Why don’t you take it all the way and make the quantity and unit price unsigned?

In your code I presume you never have a line that looks like this:

if( orderLine.Order != null ) or if( orderLine.Product != null )

Right? Because the Order and Product will never be null. Until some off the wall requirement is introduced.

I’m sure there are aspects of an OrderLine that can be tested without an order or a product.

as far as i know, everything has to be virtual if you want NH to use proxies.

the fact that members aren’t virtual by default is what makes me cringe

integrating patterns & best practices in tools is obviously good, but generated code doesn’t really fit into that category IMO, unless we’re talking about really small stuff. I’ve seen how code generation based on the database structure leads to a host of problems time and time again, and there’s really nothing that can get me to ever consider it again.

Why not integrate your knowledge in a tool so that others don’t have to go through the full learning curve you went through, and save yourself some lengthy code reviews ?

Isn’t it a possible solution to what you wrote here :
http://davybrion.com/blog/2009/03/why-dont-we-learn/

Integrate the collective knowledge in tools (patterns & best practices), so that we can continue to raise the abstraction levels … sounds good to me )

as for having to keep it consistent manually… i still see the consequences of code generation taken too far on a semi-daily basis and i’m pretty much convinced by now that keeping your model consistent manually takes less long-term effort than any kind of code generation

Would be nice if we could integrate a standardized way of creating a DDD model in ActiveWriter (too bad days are not 48 hours long lol).

Question : do you usually manage bi-directional relations in a generic way or you handle it in Create / Remove methods ?

public virtual int Id { get; private set; }

interesting comment… first i thought “how could an Order create an OrderLine instance if its constructor was not public?”. Obviously, making the OrderLine constructor internal would enable the Order class to create instances of it, while at the same time allowing you to control the creation of OrderLines through its aggregate root (Order). Which is nice, assuming that the rest of your assembly doesn’t create OrderLine’s outside of the control of the aggregate root (which it shouldn’t, although it would be possible).

But for people who aren’t doing DDD, that might be pushing it a little bit too far.

ie.

order.CreateOrderLine(product, quantity);
order.CreateOrderLine(product, IDiscount, quantity);