Bevan, I agree with you on avoid using public fields from pure OOP (Object Oriented Programming) point of view. However, remember we are dealing with the mapping of objects in memory to rows in database tables. The objects are mostly not the same as OOP business objects. They are called Transfer Objects (TO) or Value Objects (VO). They consists of only attributes (fields or properties) without any operations. They are created for convenience. I have seen them in many books by well known experts in the industry.
By the way, if you know web service, please take a look at the proxy classes generated from a WSDL by Microsoft xsd.exe in the visual studio.net - they are EXCLUSIVELY public fields. I have run into situations with files of huge size which bring Visual Studio to its knees. Using public fields in that situation makes practical sense (cutting down the size). Thanks a lot for your reply on the subject. Ling --- Bevan Arps <[EMAIL PROTECTED]> wrote: > > Ling Wang wrote: > > > ... it would be nice if iBATIS can support mapping > > of public fields besides properties (getters and > > setters). Do you know if that is already on the to > do > > list? If yes, any idea when will it be > implemented? > > In my experience, public fields are a massively bad > idea. I believe this > opinion to be shared by much of the wider industry. > > For example, the FxCop tool has an explicit rule > against them: > > *Do not declare visible instance fields* > http://www.gotdotnet.com/team/fxcop/Docs/Rules/Design/DoNotDeclareVisibl > eInstanceFields.html > > Given also that IBatis.NET is a tool that enables > "Best Practice" design > (particularly separatation of concerns), I would > strongly suggest that > it should *not* support mapping of public fields. > > My 2c, > Bevan. > > > ****************************************************************************** > "This message (and any files transmitted with it) > are confidential and > may be legally privileged. If you are not the > intended recipient please > notify the sender immediately and delete this > message from your system. > > This message does not necessarily reflect the views > of the > Reserve Bank of New Zealand. If the recipient has > any concerns > about the content of this message they should seek > alternative > confirmation from the Reserve Bank of New Zealand." > ****************************************************************************** > > > >
