Okay, so I'll look at pursuing that route for Gender. Then what's the
best way to get a list of valid Gender's for displaying in the UI?
Something like (haven't tested this, just pulled it from the reference
docs -- the Cat example):
List<Gender> genders = new List<Gender>();
IQuery query = session.CreateQuery("select c from Gender as c");
foreach (Gender g in query.Enumerable())
{
genders.Add(g);
}
Am I on the right track?
On Feb 9, 7:49 pm, Jason Meckley <[email protected]> wrote:
> the list of genders (or whatever look up) should be separate from the
> actual entity. validation can be done any number of ways. attributes,
> Validator<T>, or a series of simple bool returning members on the
> entity itself. I would treat Gender as a value object/entity using NH
> mappings instead of a string. this would allow for strategies of
> gender specific functionality. instead of logic like
>
> if(person.gender == "M"
> {}
>
> else if(person.gender == "F")
> {
>
> }
>
> you could do
> person.gender.dosomething();
>
> i would probably go with a combination of validation attributes
> (castle validation component) and IValidator<T> where the validation
> logic can be placed in a central location. The systems I design are
> small so I find this works well for me.
>
> On Feb 9, 7:04 pm, Dathan <[email protected]> wrote:
>
> > Something like
> > PersonTbl (PersonId INTEGER PRIMARY KEY IDENTITY(1,1), Name NVARCHAR
> > (255), GenderId INTEGER REFERENCES GenderTbl(GenderId));
> > GenderTbl (GenderId INTEGER PRIMARY KEY IDENTITY(1,1), Gender NVARCHAR
> > (10));
>
> > But where Person.Gender is a string, and is at some point by the DAL
> > resolved into the GenderId that corresponds to the value of the Gender
> > column with the same string value.
>
> > The contents of GenderTbl should never be changed by the DAL (I don't
> > want users defining new genders!), but we do have a case where users
> > being able to add to such a list might be necessary (e.g., it might be
> > necessary to allow users to add new cities to our gazeteer). So,
> > since I'm a newbie to the terminology, yes, you might say the Gender
> > list is persistent, but I'm not trying to persist a collection of
> > genders per person. Just a single Gender per person, plus supporting
> > some mechanism for validating that what the user has selected in the
> > frontend is a valid gender.
>
> > But I guess even that's not quite right... I don't want to persist a
> > Gender object per Person (a one-to-one relationship). I want to
> > create a many-to-one relationship where each Person has a reference to
> > either the, e.g., "Male", "Female", or "Unknown" gender. But I'd like
> > to be able to, somewhere (and it just makes sense to me to do it as
> > part of the object model, rather than externally in the UI logic), get
> > a list of all valid genders (currently I do this as a string -- would
> > it make more sense to create a Gender object for this?) for use both
> > in validating user input (is the user's input in the set of valid
> > genders?), and in UI presentation.
>
> > On Feb 9, 4:39 pm, Fabio Maulo <[email protected]> wrote:
>
> > > The "Gender" list is persistent ?
>
> > > 2009/2/9 Dathan <[email protected]>
>
> > > > Thanks for the reply!
>
> > > > The list is, as you surmise, for UI drop-down population, but also for
> > > > run-time validation. I'd rather validate the value of the Gender
> > > > property immediately (via either Dictionary.ContainsKey() or List.Find
> > > > (), as you suggest) than waiting for NHibernate to throw an error when
> > > > I try to serialize the entity back to the data store (I'm an NH
> > > > newbie, so please correct me if I'm wrong about the behavior in this
> > > > regard). I'm open to advice on best practices, though, if this is the
> > > > wrong way to go about it.
>
> > > > Given that a list of valid genders is also of use in data validation
> > > > (which seems to be very much a domain concern, rather than strictly a
> > > > UI concern), not just UI control, it seems logical to me that embedded
> > > > in the person entity is an appropriate place for this information. I
> > > > take it this is contrary to DDD / MVC / other best practices?
>
> > > > ~Dathan
>
> > > > On Feb 9, 3:33 pm, Jason Meckley <[email protected]> wrote:
> > > > > why does the person entity have a static list of genders? if it's just
> > > > > for UI dropdown list selection, this can, and should, be done outside
> > > > > to scope of the person entity.
> > > > > I would also recommend using 2nd level cache for memory storage of the
> > > > > gender list rather than a static list. and I would recommend waiting
> > > > > on implementing the cache until
> > > > > 1. preformance is a documented and measurable issue
> > > > > 2. the problem is loading the genders and not another issue (select n
> > > > > +1 or unrestricted list results).
>
> > > > > the person entity would just have a Gender property which you would
> > > > > get;set; to a Gender field. no need for a dictionary of genders within
> > > > > the person entity. also, if you are going to keep a collection on any
> > > > > entity. use IList<T>, in this case IList<Gender>. key, value
> > > > > containers do not express intent and the same functionality can be
> > > > > gained using list.Find(predicate).
>
> > > > > On Feb 9, 12:45 pm, Dathan <[email protected]> wrote:
>
> > > > > > I'm considering porting my existing DAL to NHibernate instead. But
> > > > > > I've been reading the documentation, and there's one feature of the
> > > > > > way my object model currently works that I haven't figured out an
> > > > > > elegant way to do using NHibernate yet.
>
> > > > > > Say I'm representing a person. That person has a Gender property.
> > > > > > In
> > > > > > the database, that gender property is a foreign key to
> > > > > > GenderTbl.GenderId, and GenderTbl.Gender holds the string that
> > > > > > describes the person's gender. What I'm doing currently is having
> > > > > > something like the following:
>
> > > > > > public class Person
> > > > > > {
> > > > > > private string gender;
> > > > > > private static Dictionary<string, int> genderDict;
> > > > > > private static IList<string> genderList;
> > > > > > .
> > > > > > .
> > > > > > .
> > > > > > public string Gender
> > > > > > {
> > > > > > get
> > > > > > {
> > > > > > return gender;
> > > > > > }
> > > > > > set
> > > > > > {
> > > > > > if (!genderDict.ContainsKey(value))
> > > > > > throw new ArgumentException("Invalid gender");
> > > > > > gender = value;
> > > > > > }
> > > > > > }
>
> > > > > > public IList<string> GenderList
> > > > > > {
> > > > > > get
> > > > > > {
> > > > > > return genderList;
> > > > > > }
> > > > > > }
>
> > > > > > }
>
> > > > > > My DAL initializes Person.genderDict and Person.genderList to
> > > > > > reflect
> > > > > > the contents of GenderTbl -- genderDict is used to lookup the
> > > > > > primary
> > > > > > key of a gender when the Person is serialized back to the database
> > > > > > (there's a UNIQUE constraint on GenderTbl.Gender, so this reverse
> > > > > > lookup will be valid). I could just as easily do something like:
> > > > > > private int gender;
> > > > > > private Dictionary<int, string> genderForwardDict;
> > > > > > private Dictionary<string, int> genderReverseDict;
> > > > > > public string Gender
> > > > > > {
> > > > > > get{ return genderDict[gender];};
> > > > > > set{ if (!genderReverseDict.ContainsKey(value)) throw new
> > > > > > ArgumentException(); else gender = genderReverseDict[value];}
>
> > > > > > }
>
> > > > > > And I'd be fine with that. What I haven't figured out is how to get
> > > > > > NHibernate to populate a static list of the legal values for the
> > > > > > gender field (genderDict). Or is there some other way to do this
> > > > > > that
> > > > > > I'm missing? Specifically, I do this so view-related controls can
> > > > > > bind to the list of legal values so the user can select from a combo
> > > > > > box rather than having to perform a search every time or type in a
> > > > > > string, etc.
>
> > > > > > Thanks!
>
> > > > > > ~Dathan
>
> > > --
> > > 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
-~----------~----~----~----~------~----~------~--~---
