In my experience, maps can be better when the database is driving. When the purpose of the application is to expose the database, then most of the map attributes can correspond directly to database fields. You can also use the same tokens. If the database calls the fact birth_date, then the fact is birth_date, and everybody knows that, because the database says so.
The type safety afforded by properties can be helpful, but it doesn't come close to solving the problem. Even after you have a date, there's the question of whether it's in the correct range. So, we end up declaring the type as a property and again as part of the input validation. I do understand the value of type safety, but I also understand the value of not repeating yourself. :) When using maps, you can document the attributes through a static class of constants. To use code completion, you can just start typing the name of the static class. With a modern IDE, like IDEA or Resharper, It's also quite easy to find every place an attribute is used, and it's just as easy to refactor the attribute name. The data type, including any constraints, should also already be documented as part of the data schema. Even without referring to the data schema, most basic types, like dates, can be communicated through naming conventions that any sane database should already be using anyway. Of course, if you are not using a well-documented database with online documentation (we use Confluence), then don't try this at home. If the database is not driving, or the database blows baby chunks, then, yes, it's a much better idea to create your own property-based model within the application. In my experience, there's at least two best practices for every problem. Sometimes you waterfall, and sometimes you agile. Sometimes you hibernate, sometimes you ibatis. Sometimes, you property, and sometimes you map. One-size-fits-all is the pointy-hair grail :) -Ted On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > It's ironic to me that I had this same discussion with someone at work > just last week :) > > I *was* in the "Maps are better" camp until a few months back when I > changed my mind, and it comes down to one thing: > > Self-documenting code is better. > > A bean is self-documenting in that you can immediately tell what its > attributes are and what types they are. I'm not even talking about > generating javadoc from the source either, but that's certainly a very > nice by-product. > > Developers HATE documenting. I'm sure there are exceptions, but by and > large that is a very fair generalization in my experience. If you trust > a developer to document what is going into a Map, your asking for > trouble, generally-speaking. > > I don't personally use an IDE, but I think Rick's point about > auto-completion and the like is important because many people *DO* use > IDEs, and if you give them a bean they can be more effective faster than > if you give them a map with some documentation on what they may find in > it at various points in time, and that's even assuming the documentation > is accurate :) > > Especially in a team environment, I would always go with a real bean now > over a Map-based design, even though I agree with may of the points made > on why Maps are good. But in this world of trade-offs, I think you gain > more by using a bean than you do by using a Map, again, generally-speaking. > > Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
