It depends. Generally speaking enterprise apps are tiered, so if you expect the app to grow, or others in your organization will be working on this app, there's a good chance that you need to introduce at least one tier. Typically you have a data access tier, which is an API (a set of related classes that share a package) that wraps all your SQL code and has methods along the lines of "create()", "update()", "delete()" and "read()". Then, there's typically a tier that manages the relationship between your form and this data access tier (a "controller") that has the job of pulling the data out of your form, invoking the data access tier as necessary, and then giving control to some other view (screen, whatever). Often there's another tier (business rules) that has the job of enforcing rules about what can be done to the data tier, and in which case the controller often delegates much of its behavior to that tier (with the exception of choosing the next view to display).
These are general guidelines, and there are many variants on this approach. The idea is that each of these areas of focus have a distinct purpose that will grow/change with time, and should therefore be separated from one another.