sabi for Rust

A small framework for Rust designed to separate logic from data access.
It achieves this by connecting the logic layer and the data access layer via traits, similar to traditional Dependency Injection (DI). This reduces the dependency between the two, allowing them to be implemented and tested independently.
However, traditional DI often presented an inconvenience in how methods were grouped. Typically, methods were grouped by external data service like a database or by database table. This meant the logic layer had to depend on units defined by the data access layer's concerns. Furthermore, such traits often contained more methods than a specific piece of logic needed, making it difficult to tell which methods were actually used in the logic without tracing the code.
This crate addresses that inconvenience. The data access trait used by a logic function is unique to that logic, passed as an argument to the logic function. This trait declares all the data access methods that specific logic will use.
On the data access layer side, implementations can be provided in the form of default methods
on DataAcc derived traits.
This allows for implementation in any arbitrary unit — whether by external data service, by table,
or by functional concern.
This is achieved through the following mechanism:
- A
DataHubstruct aggregates all data access methods.DataAccderived traits are attached toDataHub, givingDataHubthe implementations of the data access methods. - Additionally, the data access traits that logic functions take as arguments are also attached
to
DataHub. But that alone wouldn't work in Rust because methods aren't overridden across traits, even if they have the same name and arguments, leaving the logic-facing data access trait methods without implementations. - This is where the
override_macrocrate comes in: it adds the method implementations of the logic-facing data access traits by calling the corresponding methods from theDataAccderived traits. (While it's possible to implement this by hand withoutoverride_macrocrate, it becomes very cumbersome for a large number of methods.)
Installation
In Cargo.toml, write this crate as a dependency:
[]
= "0.4.0"
Usage
1. Implementing DataSrc and DataConn
First, you'll define DataSrc which manages connections to external data services and creates
DataConn.
Then, you'll define DataConn which represents a session-specific connection and implements
transactional operations.
use ;
use Err;
2. Implementing logic functions and data traits
Define traits and functions that express your application logic.
These traits are independent of specific data source implementations, improving testability.
The #[overridable] macro is used to allow these trait implementations to be overridden later.
use Err;
use overridable;
3. Implementing DataAcc derived traits
The DataAcc trait abstracts access to data connections.
The methods defined here will be used to obtain data connections via DataHub and perform
actual data operations.
The #[overridable] macro is also used here.
use DataAcc;
use Err;
use overridable;
use crate;
4. Integrating data traits and DataAcc derived traits into DataHub
The DataHub is the central component that manages all DataSrc and DataConn,
providing access to them for your application logic.
By implementing the data traits (MyData) from step 2 and the DataAcc traits
from step 3 on DataHub, you integrate them.
The #[override_with] macro indicates that the methods of the MyData trait
will be provided by the corresponding methods of the DataAcc derived traits.
use DataHub;
use override_with;
use Err;
use crateMyData;
use crate;
5. Using logic functions and DataHub
Inside your main function, register your global DataSrc and setup the sabi framework.
Then, create an instance of DataHub and register the necessary local DataSrc using
the uses method.
Finally, use the txn! macro to execute your defined application logic
function (my_logic) within a transaction.
This automatically handles transaction commits and rollbacks.
use ;
use crate;
use cratemy_logic;
Using this framework in async function/block
If you want to run this framework within an async function/block, you should use setup_async
instead of setup, run_async! instead of run!, and txn_async! instead of txn!, as shown
below.
async
async
Supported Rust versions
This crate supports Rust 1.85.1 or later.
)
)
License
Copyright (C) 2024-2025 Takayuki Sato
This program is free software under MIT License. See the file LICENSE in this distribution for more details.