PersonName is a perfectly valid example of a value object. FirmId is not. The POID of your class is an int. It would be a different case if you were using composite identifiers (which ARE supported by NHibernate, and are almost always a bad idea, except for legacy DBs)
Diego On Tue, Jun 15, 2010 at 17:24, Trinition <[email protected]> wrote: > Diego, I whole-heartedly agree. I didn't invent this. Immutable > value objects are an important part of domain-driven design (see: Eric > Evan's book) and fluent API's also use semantically strong APIs. > > Regards, > Brian. > > On Jun 15, 10:23 am, Diego Mijelshon <[email protected]> wrote: > > When I find myself doing something in a way that's completely different > from > > everyone else, I ask myself: "Am I a genius and this is a revolutionary > > idea, or is this just a hack that will bite me later?" > > > > You'd be surprised at how few the instances of the former are. > > > > Diego > > > > > > > > On Tue, Jun 15, 2010 at 10:13, Trinition <[email protected]> wrote: > > > Diego, I fear you've misunderstood what I'm trying to do. I'm not > > > trying to protect myself form the compiler, but to have a semantically > > > complete API. I don't simply pass around person names as 'strings' > > > but as PersonName's, which have a stringer semantic to them than just > > > a string (as well as constraining their possible domain of values). > > > I've been through many projects on many jobs where problems arise from > > > anemic types. > > > > > I can use strong, semantic types for any general property in an entity > > > destined for mapping in NHibernate by using <composite>. However, I > > > can't use that for an ID. > > > > > I see that you view these "wrappers" as nonsense, but I argue they're > > > far from it. > > > > > As for being easier to work with the frameworks, I've found no > > > friction from doing it this way *except* for identifiers. > > > > > Regards, > > > Brian. > > > > > On Jun 14, 2:46 pm, Diego Mijelshon <[email protected]> wrote: > > > > So, you essentialy tried to protect you from yourself by abusing the > > > > compiler. > > > > Why stop with IDs? Write a wrapper for every property, so you can't > > > > accidentally assign a ClientBirthDayDateTime to a > > > PaymentDueDateDateTime... > > > > > > My suggestion: remove all that wrapper nonsense. It's easier to work > with > > > > the frameworks than against them. > > > > > > For the record, "var" doesn't have a type, it's a keyword that > triggers > > > > implicit typing. > > > > > > Diego > > > > > > On Mon, Jun 14, 2010 at 11:04, Trinition <[email protected]> > wrote: > > > > > Sure, an int is more strongly typed than 'var', but one can't > > > > > distinguish an int representing a Client's ID from an int > representing > > > > > an Organization's ID. But surely you wouldn't want to confuse the > > > > > two. > > > > > > > So far, I have been pointing to a private field. The problem > occurs > > > > > with NHIbernate's LINQ because the public property I'm exposing to > my > > > > > domain (including my repositories which use LINQ) aren't known to > be > > > > > mapped by NHibernate, so it can't convert them to a query. For > > > > > example: > > > > > > > class Client { > > > > > private int _id; // Mapped as the identity in Client.hbm.xml > > > > > public ClientId Id { get { return new ClientId(_id); } } // A > > > > > generated, strongly-typed wrapper > > > > > } > > > > > class ClientRepository { > > > > > public IList<Client> GetSpecificClients(IList<ClientId> clientIds) > > > > > { // This is a contrived example > > > > > return _unitOfWork.Find<Client>().Where(client => > > > > > clientIds.Contains(client.Id)).ToList(); // 'Id' property of Client > is > > > > > not known to NHibernate! > > > > > } > > > > > } > > > > > > > That is why I'd prefer to use my ClientId class directly as the > > > > > identity type for Client. > > > > > > > Regards, > > > > > Brian. > > > > > > > On Jun 11, 9:04 pm, Diego Mijelshon <[email protected]> > wrote: > > > > > > How is an int _not_ strongly-typed? What value do those wrappers > > > provide? > > > > > > In any case, you can always point NHibernate to your private > field, > > > and > > > > > it > > > > > > will skip your wrapper completely: > > > > > > > > <id name="_Id" access="field" type="Int32"> > > > > > > <generator class="..."/> > > > > > > </id> > > > > > > > > Diego > > > > > > > > On Fri, Jun 11, 2010 at 16:12, Trinition <[email protected]> > > > wrote: > > > > > > > In my domain, I'd really prefer to have strongly-typed IDs > (simple > > > > > > > immutable wrappers around ints). This would allow me to have > clear > > > > > > > method signatures and allow Intellisense to assist me more > > > accurately: > > > > > > > > > public void ResetFirmLockout(FirmId firmId); // Consider this > > > strongly- > > > > > > > typed identity... > > > > > > > public void ResetFirmLockout(intfirmId); // Consider this > > > weakly-typed > > > > > > > identity... > > > > > > > > > It may sound trivial, but I've pulled it off half-way and it > has > > > been > > > > > > > quite nice to have it this way (I'm using a private int field > "_id" > > > > > > > but exposing a readonly-property to the domain of type FirmId > that > > > is > > > > > > > constructed on the fly). > > > > > > > > > The only problem is that I can't get NHibernate to recognize a > > > > > > > component as it's identiy. The "<id...>" takes a Type that > must be > > > an > > > > > > > NHibernate type like "Int32". I can't specify a user type such > as > > > > > > > "FirmId". > > > > > > > > > I've also considered <composite-id>, but it only works with > > > > > > > application-assigned identifiers, whereas I do want to rely > upon > > > DB- > > > > > > > generated identities. > > > > > > > > > I considered a custom IIdentityGenerator, but as best I can > tell, > > > it > > > > > > > would still have to be an NHibernate type (e.g. "Int32"). > > > > > > > > > Has anyone else ever accomplished this? > > > > > > > > > -- > > > > > > > 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]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]>> > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%252bunsubscr...@googlegroup s.com>> > > > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%252bunsubscr...@googlegroup s.com> > > > <nhusers%252bunsubscr...@googlegroup s.com>> > > > > > > > . > > > > > > > For more options, visit this group at > > > > > > >http://groups.google.com/group/nhusers?hl=en. > > > > > > > -- > > > > > 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]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]>> > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%252bunsubscr...@googlegroup s.com>> > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/nhusers?hl=en. > > > > > -- > > > 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]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]>> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/nhusers?hl=en. > > -- > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- 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.
