Getting Startedwith pureQuery

14
Chapter 14 - Best Practices
In the previous chapters of this book, we have introduced pureQuery and described in
detail its major components: API, runtime and tools. In this chapter we will describe best
practices for each one of those components.
14.1 Best Practices: The big picture
pureQuery is a platform designed to deliver increased productivity to developers, and
improved performance, maintainability, monitoring and security for applications. In addition
to the improvements that your application will get by using pureQuery, there are still some
best practices that help you get the most out of pureQuery in certain scenarios. In this
chapter, we will go over some of those best practices and will identify in which scenario we
recommend their usage.
Previously to the writing of this book, the pureQuery team has also published an article on
some best practices, titled “Write high performance Java data access applications, Part 3:
Data Studio pureQuery API best practices”. This article was part of a series on developing
high performance Java data access applications and the list of best practices covered
focused on the pureQuery API. In this chapter, we will provide some additional best
practices that focus not only on the API, but also on the tools and runtime components.
14.2 Choose your style: inline vs annotated method style
In Chapters 12 and 13, we described the Inline and Annotated method programming styles
for the pureQuery API. Both styles have their own advantages, so here are some
guidelines on which style to pick when developing your pureQuery application:
Use pureQuery annotated style if you:
• Want to use static SQL at runtime
• Prefer to have your SQL separated from your business logic
• Want a simple data access layer code generated by the Optim Development
Studio tooling
• Like to use XML files to define your data access layer