Take it as something like this....To use a very good persistence layer as NHibernate you must pay something... to have a private default ctor is a really cheap cost ;) To use lazy-loading in a entity instance without inherit from a special class (that mean use a DynamicProxy system) you must pay something... have all virtual methods it is not so cheap but it is an acceptable cost to pay for a so powerful feature. To use lazy-loading for a collection you must pay something... you can declare a ConcreteCollectionClass in your entity but you must use an interface; another cheap cost
In this capitalist world nothing is for free ;) 2008/12/30 Krzysztof Koźmic <krzysztof.koz...@gmail.com> > Now *that* was an exhaustive answer. > > Actually when, I think about what you said about different constraints in > different contexts it makes sense. > It's just moving the burden of ensuring the validity of an entity from the > compiler level up. > In this case, If I have, say, a Customer by bussiness rule requires it to > have a name and an address (for example), bu this is not enforced by the > compiler in form of required .ctor parameters, checked for null. > I'm still however not completely sold on this idea, here's why. > > If I can write "new Customer()", I can't make any assumptions about it. > At any point, calling Customer.Name.ToUpper() may result in > NullReferenceException. > > from domain point of view, it would make sense to keep it readonly and > injectable by constructor, so that I have an explicit contrant: "If I get a > customer, it *always* has a non-null name". Without it, I'd have to check it > for null all the time. > > Now, back to persistence: If I require Name to be not-null, if I get a > customer from the DB, it seems reasonable that ORM should figure out that > Name it just got from the DB should be put as .ctor parameter "name", as it > corresponds to Name property defined in the mapping. > > With that I get better encapsulation, and I'm less persistance-dependent. > > Still, I may be totally wrong here. > > Krzysztof > > > Fabio Maulo pisze: > > Yes I understand that you are not talking about IoC but what you want is to > use a specific ctor for business constraint. > If you want you can do it using a specific tuplizer for each entity but it > is to much work for you; for that reason "we" prefer to have a private > default ctor for persistence matters and a public ctor for business matters. > If you use a no default ctor you are loosing some other feature as "query > by example" and something else... > > Now... (IMO) > -If I write "new Customer()" there is no problem until I don't use that > instance for business matters... > Well perhaps a "Customer" is not a better example here... what about a "new > DateTime(1,1,1)" ? > > -In theory each class may have different rules in different context; a > customer sure must have a "denomination" but is you want use it in an > invoice it must have an Address; for an Invoice an Address with Street and > Number is enough but if you want use it to send Products to the Customer the > Address must have a PostalCode. For each of these constraint you may have a > specific ctor but at that point is better to have a "ValidatorClass" to > validate each instance in each specific context. > > -The ctor constraint may have sense when you are creating a really new > instance but when the instance come from DB is because it is , in general, a > valid persistent instance and for that the default ctor is more than enough. > > > The end: > If you want work a lot use a specific tuplizer for each entity class to use > a specific ctor. > If you don't want work a lot use a private default ctor. > > > 2008/12/30 Krzysztof Koźmic <krzysztof.koz...@gmail.com> > >> Fabio, >> >> I've read that post. That is not however what I've been talking about. >> What in case >> >> Invoice >> >> class from your example took in its .ctor not only calculator but also >> description (and if description property and field was readonly) >> >> Krzysztof >> >> Fabio Maulo pisze: >> >> http://fabiomaulo.blogspot.com/2008/11/entities-behavior-injection.html >> >> 2008/12/29 Krzysztof Koźmic <krzysztof.koz...@gmail.com> >> >>> >>> I'm thinking, why actually NHibernate require entities to have >>> parameterless constructor. >>> I know that I can make it non-public, but still, for a lot of entities >>> it simply smells. For example, it doesn't make sense to have a customer >>> without name, or Order without Item. To throw a buzzword at you, it's >>> persistence-ignorance hole. A requirement I must satisfy in order to use >>> certain persistence mechanism. >>> What if, instead NHibernate was smart enought to use the non-default >>> constructor? >>> for example if I have a customer class >>> >>> public class Customer >>> { >>> private readonly string name; >>> >>> public Customer(string name){...} >>> >>> public string Name { get {...}} >>> } >>> >>> Why can't NHibernate figure it out how to create a customer, when it >>> already has all it needs (a name). >>> Does it make even sense? >>> >>> Cheers, >>> Krzysztof >>> >>> >>> >>> >>> >>> >> >> >> -- >> Fabio Maulo >> >> >> >> >> >> > > > -- > Fabio Maulo > > > > > > > -- Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to nhusers@googlegroups.com To unsubscribe from this group, send email to nhusers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
