Separating the UI from its event handlers and database queries

Question

Is it a good practice to separate the handlers and database queries in different classes?

There will be a separate class containing all the necessary event handlers, and there would also be another class for database queries?

Answer 1

Absolutely yes, your code should (almost) always have a separation of concerns:

In computer science, separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity of programming and encapsulation (or "transparency" of operation), with the help of information hiding. Layered designs in information systems are also often based on separation of concerns (e.g., presentation layer, business logic layer, data access layer, database layer).

There are a ton of software design philosophies and patterns behind this, but the Single Responsibility Principle (SRP) is probably a good default to always use:

In object-oriented programming, the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

Rough translation is: "Your class/method/function should do one thing and do it well"

Answer 2

+1 for Emmad Kareems answer, but I would also add that your database queries should be implemented (if possible) as stored procedures in your database becase they are easier to unit test/debug (because you can run them without your code). They make change easier as for some changes you only need to change the procedure, and not your code base. They also run faster because the DB engine will pre compile them and store statistics on them which it probably wont do for queries that are coded into you app.

And yes, the N teir approach works with any language you like - even scripting languages - you just need to find the correct pattern/code/library for the situation.

Answer 3

The answer to your question is Yes. It is a good idea to separate your application into classes, components and layers. A more sophesticated separation can be achieved using a famous design architecture called N-Tier Architecture where an application physically separate its components into separate physical tiers (not only logical layers). It has many advantages that I would recommend you get to know if you haven't already done so. See for example this:

N-Tier

Another famous design pattern that promotes more independence of the GUI (Wikipidia cosniders it an Architecture) is MVC (Model-View-Controler) - See about it here:

MS-Model-View-Controler-Intro

MVC-Better-Code-Organization

A discussion about N-Tier and MVC may also be useful - See this:

MVC-VS-NTier

Before you use any of this stuff, you need to justify the effort and cost of the learning curve. N-Tier and MVC applications may be classified as "advanced" programming techniques and may be harder for those not familiar with the concepts, so is it worth it?