Hi,
I want to create an API for the GUI piece of my application to hook up to. The GUI will basically query a database and display the results, it will also be used to edit database rows. Are there any patterns that I can use for this activity so that either the front or back end technologies can change without effecting my API and so I can change or add new queries without effecting the code?
Thank you in advance.
> I completely agree, although I have an extremely
> limited time to do this and simply don't have the
> time to learn these technologies now. I just need a
> good design for this initially and move to these
> technologies later
no need for any particular patterns. simply following good OO principles is key here. keep your UI logic and your business logic and your data access logic separated. a good test is to write 2 interfaces, for example a GUI and a command-line client. if you find you have to tweak code to fit different interfaces, your logic has leaked. but basically, you want a layer of separation between the UI and the data layer. the middle layer mediates between the 2. a good starting point is get rid of any data access logic from your UI code. it shouldn't care less whether its data comes from a database, flat files or is just generated at random by your middle layer
> I that your suggestion?
My suggestion is that you're asking the wrong question with respect to patterns. Design patterns are repeatable solutions to a particular kind of problem. Once you've identified the problem, look for a pattern; not the other way around. Don't waste your time trying to shoehorn a bunch of patterns into your application; concentrate instead on designing your app so it makes sense.
That said, it's probably a good idea to be familiar with some common patterns, so you'll have a lexicon of solutions for problems you're likely to encounter. To that end, here are some excellent resources:
[url=http://www.patterndepot.com/put/8/JavaPatterns.htm]The Design Patterns Java Companion[/url]
[url=http://www.wickedlysmart.com/HeadFirst/HeadFirstDesignPatterns/HeadFirstPatternsIndex.html]Head First Design Patterns[/url]
[url=http://home.earthlink.net/~huston2/dp/patterns.html]Huston Design Patterns[/url]
[url=http://www.mindspring.com/~mgrand/pattern_synopses.htm]Overview of Design Patterns[/url]
~
> > I fully understand the arguments against
> shoe-horning code into a pattern...
>
> The problem isn't that you're shoe-horning code into
> a pattern; it's that you're trying to shoe-horn a
> pattern into your code.
and that unfortunately, is an all-too-common phenomenon.
Well,
You may try Template method since you are actively looking for a "template" design pattern.
In an abstract,
class abstract DisplayRecordSet {
public result;
public void retrieveRecord() {
connectDB();
executeQuery();
closeDB();
}
abstract connectDB();
abstract closeDB();
abstract executeDB();
}
class ConcreteRecord extends DisplayRecordSet {
public connectDB() {
//connect to your DB
}
public closeDB() {
//close connection
}
public executeQuery() {
//run your query and set to the result variable
}
}
From above, you can add more queries as you like buy adding new subclasses.
Well, on the other hand, this may cause a lot of classes to be create when queries increases. But you can always apply another pattern to solve that issue.
Hope that helps.
-chiew boon
