...

/

Project Structure

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.

Press + to interact
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 ...