If you have a table named "sites" what do you name your entity and
the corresponding class? Sites or Site?
Keep table / entity name singular
Few of my own « best practice », mainly due to the fact that most of
these share their namespace in their domain:
- prefix table-name with their domain intent. Because when your
database grow, it may append that the « user » table is taken already
for users of your application, and now business envolve and you also
need to track the « user » of some « project ». Having domain prefix
allow for « app_user », and « product_user » to share the same bd.
- having a domain prefix to table-name, also allow you to group table
toghether in database gui editor. For example, in a simple library
management system, we have all the product related table prefixed with
"prod_" (prod_book, book_author, etc...) and the user prefixed with
"usr_" (usr_person, usr_group, usr_permission, etc.). in this simple
system I think I have 4 groups of table (from memory). It is not a
necessity, but I like the fact that tables are grouped toghether at
least by their names. This is very handy when you have many tables
(50+), do some search and refactoring.
- have a domain prefix for the entity name, can be the same as for the
table, or more closely match the package name, it depend. Because all
entity name share the same namespace, this is convenient when you
suddently incorporate a new model to allow credit-card payement and
this model already have a « user » entity in it.
- allow non exact match of entity name and class name and table
name ... but still be coherent and consistent. Table can be
"usr_person", entity can be "User_Person" and class can be
"org.mydomain.usr.Person". ... for me it's close enough. Anyway in
java code, you use constants defined by the eogenerator template.
Java already have package to isolate class namespace, classes do not
need to duplicate prefix in there (org.mydomain.usr.UserPerson) just
because model and table share a single namespace ... be different.
I would like to ear your model-level best practice, most likely I will
end up using some of them.
- jfv
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
