floater
Java Jedi
总版主
发贴: 3233
积分: 421
|
于 2004-06-16 03:05
I moved this post to here for further discussion. I just contribute some of my thoughts here too:
1. Page 3, VOs should be replaced with interfaces. We should *not* pass objects between layers, but interfaces. Each layer could have its own implementation of the interfaces. The interfaces should belong to the business layer(why???) 2. Page 4, add/remove/update methods should have parameter user, not integer. Don't expose implementation. What if one day we need to change this id to 36 digit guid? Changing from 3-digit to 4 caused an earthquake in my working company, what if more than that? 3. Page 4, yes, normally we shouldn't care about db shifting in business applications, unless we are doing some middleware or like, e.g., forums/jive. 4. Page 6, yes, start from db side, get schema done first, then use middlegen hibernate to generate hbm files, then use tools to generate java classes(be careful here when you go hbm-->java, if you have inheritance, you have to read in parent hbms first before you read in child hbms). One more note: After we settle the business layer, the schema could be derived in several ways, read scott ambler's articles for 4 ways to do this. 5. Page 7, JDBCTemplates etc could be done better in the following: a. queryForObject/Long/Int should be improved to return a uniform object, like in SQLExecutor interface. Same as input. SQLExecutor's interface is nices to api callers. b. not sure about callbacks and inner classes, seems we just do what SQLExecutor does, it will be good enough. 6. Page 10, on datasource. The settings for different layers should be in seperate files(although we may read all of them into the context) so each layer is independent of others. Sample code constantly misleads this. And I don't like to read settings from resources from classpath because the collision is uncontrollable. 7. Page 11, web layer. General speaking, there are 3 kinds of presentation tools: a. velocity: scripting based b. xml: xslt, xml based c. tapestry: object based jsp based is somewhere in the middle. Others are faces, tiles, portlets. MVC model(well, not really mvc) - reads professional jsp chapter 7(new version) or 12(old version) for models, especially model 2 and 2x. Hell to struts and hail to spring, . What's wrong with spring's mvc? abuse of templates! This abuse breaks the workflow's logic(This workflow is to send output to browsers). The usage pattern is more like swing applications. You have to do things in a certain way, certain order. BUT the underlying is doing right, so still the best one so far. page 14. spring bean package: doesn't have a way to write back to files. Swing applications need this feature, like firewall settings, etc. Once users config'd, they want to save them. page 15. AOP, not sure about this. If we combine AOP and python, that's going to be something. Check Thinking in java's author's website on python. BTW, there is a Jython out there too. Others: Transactions.
questions: Why do we use spring transactions rather than Connection's autocommit or jta/jts? Why do we use spring web mvc rather than struts? What's the difference between beanfactory and applicationcontext?
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler, Refactoring - Improving the Design of Existing Code
|