Loading...

nhusers@googlegroups.com

[Prev] Thread [Next]  |  [Prev] Date [Next]

[nhusers] Re: Default constructor requirement. Krzysztof Koźmic Tue Dec 30 05:00:40 2008

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 <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>>
>
>
>     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
>
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---