Swing rich client in a multi tier context_问答_开发者

We're in the analysis/early design phase of a future Swing application where persistance is provided by a database (probably an alternative between Oracle and mySql depending on the customer's money).

Basically, the application will feature two kinds of modules :

One "admin" subsystem to feed and maintain a set of referential data ;
X other subsystems using subsets of this data and building their own objects (in the business sense), referencing elements of those subsets.

My questions are :

I'd guess the best practice is to limit the deployable Swing app only to presentation matters, and make it query a business tier on a distant server, this "deeper" app being the only one having access to the database and being responsible of persistence matters. Are there reasons why we could decide to go the other way and let the Swing apps talk directy to the DB (negating the need for a separate business tier) ? Which arguments could I give to support the business tier architecture to semi-techni开发者_高级运维cal people in the decision making process ?
Are there design considerations (frameworks, patterns, code conventions) you would advise for this kind of solution (a rich client in an n-tier context) ?
Are there tools that may help us during the coding phase, especially for the retrieval of the referential data subsets into the Swing app, cache management of those, and integrity verification (checking that the modified entities the Swing app send back to the DB does not replace other modifications submitted since the fetch) ?

A 2-tier architecture (your Swing client connecting directly to the database) is usually simpler, easier to implement and less expensive since it involves less code, fewer systems and fewer technologies (you don't need to learn about web services, Java EE etc.)

A 3-tier architecture (Swing client, application server, database server) can be beneficial if one of the following reasons apply:

If it is easier to implement the security (authentication, authorization) on the application server than on the database server. In a 2-tier architecture, you need to setup a database user for each end user and you need to properly protect all your tables and procedures. In a 3-tier architecture, you can usually use a single technical user to connect to the database.
If it is not possible to directly connect to the database from a client because the security policy forbids it or the network infrastructure (firewalls) prevents it.
If it is difficult to deploy a new version of the client software on each desktop. In a 3-tier architecture, 50% - 70% of the bugs can be fixed by just deploying a new version on the application server.

If you have to go for a 3-tier architecture, you probably want to look at Java EE (Java Enterprise Edition) and at the application servers implementing it (JBoss, GlassFish, WebLogic etc.). There's a lot of literature about Java EE best practice. But be aware that Java EE is complex and has a steep learning curve.

For the database access, I'd look at Hibernate. Besides being very well suited for database access without having to deal with the niffty JDBC details, it also supports mechanisms for preventing lost updates.

This sounds like an app tailor made for a web services implementation. Your front end calls the web service for data or returns data for persisting. The business tier runs on the server and takes care of packing up data for the clients.

For non-technical people the best way I've found is to impress them with outside experts. Find white papers on the web about Service Oriented Architecture and Web Services (probably about ten years old at this point) to show them that what you are proposing is accepted architecture. You are going to write the code - one way or other the functionality has to be there - make sure it is written in a way that can be maintained.

You can also explain that testing will be easier, coding will be easier, and addition of features in the future will be easier and more straight-forward.

\2. and 3. The apache.org site has lots of functionality already written, ready to use (when you come up to speed on how to use it.) Check out the Jakarta and Web Services project groups.

I am by no mean an expert on this, but I have some thoughts that may be helpful.
1)It is a standard practice to separate code that handles the presentation layer with code that handles business logic. Swing framework itself enforces this via the MVC pattern. Having said this, why are you thinking of a remote server interacting with the DB? It is certainly an option, but you have to take into account the various network delays. Do you care about how fast the GUI is updated for instance? You could have a presentation tear i.e. design and structure your project so that you have a layer(separate from presentation layer) interacting with the DB that is local and not in a remote server. In your question concerning arguments to non-techical people, I assume for using the remote server. If you think it must be remote you could present the benefits of decoupling, performance and the overall design.
2) If you want to have a remote business tier you could use web services. Although must it be remote?