[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
At Thu 19 Mar 2009 11:27:45 UTC, Tom Potts <tompotts@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thursday 19 March 2009 10:00, Anthony Williams wrote: > .... >> * have the GUI auto-upgrade, so the GUI always has the latest logic >> * Use a web-based UI and keep the logic in the web backend (e.g. Java >> Servlets) >> * Use RPC mechanisms to call server-side code from the GUI >> * Code the GUI as part of the database (e.g Oracle Forms) > ... > I've always find 'RADs' are invariably fine for non-enterprise level > stuff but > end up getting in the way and cause other problems at a later date. > While GUI auto-upgrades sound fine they interupt service too much and when > they fail.... > Defining object interfaces fairly well near the start of the project > is always > seems to be thes best. Add a couple of unused arguments to stored procedures > and you can modify the DB and the stored procedure without touching a > customer facing GUI and test live to ones hearts content in-house and update > the page as and when. > I avoid RPC calls from the GUI - you can do that from the DB and if its part > of the business logic thats where it should be - GUI's are really a to keep > people who dont know what they're doing happy, oh and maybe showing managers > those pretty diagrams they pretend to understand. If you think theres a > problem with that get your system to talk to mine about it. All these things have trade-offs associated with them. Stored procedures are harder to test than business logic coded outside the database. Adding unused arguments is over-engineering, and makes the code harder to understand. It's also not always ideal to define your interfaces at the start of the project; I've found that the desired interface often only becomes clear towards the end of the project. Using stored procedures also ties you to the particular RDBMS system you started with --- if you use alternative client-server call mechanisms then you can change the backend from MySQL to Oracle without touching the GUI, for example. I've used stored procedures to great effect in the past, but they are just a useful tool, not the "one true way". I've also had success using the other techniques I mentioned. They all have benefits and drawbacks, it's just a matter of what's most appropriate in a given scenario. Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html