Project Structure
Learn to structure the project under the GetX ecosystem.
Overview
Structuring the project plays a huge role in software engineering. We can write good code, but how it is stored and organized determines its scalability and maintainability. While we can structure our projects any way we like, the GetX ecosystem recommends two project structures—getx_pattern
and clean.
The benefit of organizing the codebase in one of these two structures is that they work seamlessly with Get CLI, a command-line tool in the GetX suite. This allows us to automate several tasks, such as adding pages, views, controllers, and models to the project. The best part is that we can perform the initial project setup with Get CLI’s init
command.
get init
When we execute the init
command, the interface asks us to select one of the two structures. While both are meant to organize the project and make it maintainable, they differ slightly in their approaches. Check out the projects below to understand both of these structures. Nothing has been changed; the folders and files we see here were created with the init
command.
This lesson is dedicated to explaining the project structures recommended by the GetX ecosystem. Hence, we’re limiting the discussion to Get CLI’s init
command only. In the upcoming lesson, we shall cover all the other commands in detail.
The getx_pattern
architecture
getx_pattern
is one of the simpler ways to architecture our apps. It organizes the app into three main folders: data
, modules
, and routes
. Let’s understand the role of each of these folders in detail.
The data
folder
data
folder is the place for all things data. The classes that are responsible for handling data related operations, such as fetching data from the server, adding a new entry to the database, synchronizing cache, etc. should be placed in the data
folder.
The modules
folder
modules
folder is a collection of modules. A module is an independent app component that comprises of the views, controllers and the corresponding bindings, all placed in separate subfolders.
Let’s say we have a login module. Its views
folder will contain all the widgets that are used to build ...