Golang 事务性 API 设计

Question

我正在尝试关注 Clean Architecture使用围棋。该应用程序是一个简单的图像管理应用程序。

我想知道如何最好地为我的存储库层设计接口(interface)。我不想将所有存储库方法组合到一个大接口(interface)中，就像我发现的一些示例那样，我认为在 Go 中通常首选小接口(interface)。我不认为有关管理图像的用例代码需要知道存储库还存储用户。所以我想要 UserReader、UserWriter 和 ImageReader 以及 ImageWriter。复杂的是代码需要是事务性的。事务管理属于 Clean Architecture 存在一些争论，但我认为用例层需要能够控制事务。我认为属于单个事务的是业务规则，而不是技术细节。

现在的问题是，如何构建接口(interface)？

函数式方法

所以在这种方法中，我打开一个事务，运行提供的函数并在没有错误的情况下提交。

type UserRepository interface {
    func ReadTransaction(txFn func (UserReader) error) error
    func WriteTransaction(txFn func (UserWriter) error) error
}

type ImageRepository interface {
    func ReadTransaction(txFn func (ImageReader) error) error
    func WriteTransaction(txFn func (ImageWriter) error) error
}

问题:不，我不能在单个事务中轻松地编写用户和图像，我必须为此创建一个额外的 UserImageRepository 接口(interface)并提供一个单独的实现。

作为存储库的交易

type ImageRepository interface {
    func Writer() ImageReadWriter
    func Reader() ImageReader
}

我认为这与函数式方法非常相似。它不会解决联合使用多个存储库的问题，但至少可以通过编写一个简单的包装器来实现。

一个实现可能是这样的:

type BoltDBRepository struct {}
type BoltDBTransaction struct { *bolt.Tx }
func (tx *BoltDBTransaction) WriteImage(i usecase.Image) error
func (tx *BoltDBTransaction) WriteUser(i usecase.User) error
....

不幸的是，如果我实现这样的交易方法:

func (r *BoltDBRepository) Writer() *BoltDBTransaction
func (r *BoltDBRepository) Reader() *BoltDBTransaction

因为这没有实现 ImageRepository 接口(interface)，所以我需要一个简单的包装器

type ImageRepository struct { *BoltDBRepository }
func (ir *ImageRepository) Writer() usecase.ImageReadWriter
func (ir *ImageRepository) Reader() usecase.ImageReader

作为值(value)的交易

type ImageReader interface {
    func WriteImage(tx Transaction, i Image) error
}

type Transaction interface { 
    func Commit() error
}

type Repository interface {
    func BeginTransaction() (Transaction, error)
}

存储库实现看起来像这样

type BoltDBRepository struct {}
type BoltDBTransaction struct { *bolt.Tx }

// implement ImageWriter
func (repo *BoltDBRepository) WriteImage(tx usecase.Transaction, img usecase.Image) error {
  boltTx := tx.(*BoltDBTransaction)
  ...
}

问题:虽然这可行，但我必须在每个存储库方法的开头键入断言，这看起来有点乏味。

所以这些是我可以想出的方法。哪个最合适，或者有没有更好的解决方案？

Answer 1

存储库是保存数据的地方的表示，也是一种架构元素。

事务是解决非功能性要求(原子操作)的技术细节，因此它必须像架构元素中的内部引用或私有(private)函数一样使用。

在这种情况下，如果您的存储库是这样写的:

type UserRepository interface {
    func Keep(UserData) error
    func Find(UUID) UserData
}

type ImageRepository interface {
    func Keep(ImageData) error
    func Find(UUID) ImageData
}

事务方法是实现细节，因此您可以创建 UserRepository 和 ImageRepository 的“实现”，就像内部引用一样使用。

type UserRepositoryImpl struct {
    Tx Transaction
}

func (r UserRepository) func Keep(UserData) error { return r.Tx.On(...)} 
func (r UserRepository) func Find(UUID) UserData { return r.Tx.WithResult(...)}

通过这种方式，您也可以将用户和图像保存在单个事务中。

例如，如果客户端引用了 userRepository 和 imageRepository 并且它负责 userData 和 imageData 并且它还希望将这两个数据保存在单个事务中，那么:

//open transaction and set in participants
tx := openTransaction()
ur := NewUserRepository(tx)
ir := NewImageRepository(tx)
//keep user and image datas
err0 := ur.Keep(userData)
err1 := ir.Keep(imageData)
//decision
if err0 != nil || err1 != nil {
  tx.Rollback()
  return
}
tx.Commit()

这是整洁、客观的，并且在洋葱架构、DDD 和 3 层架构(Martin Fowler)中运行良好!

在洋葱架构中:

• 实体:用户和图像(没有业务规则)
• Usecase:repository接口(interface)(应用规则:保留user和image)
• 控制者:A/N
• DB/Api:客户端、tx、存储库实现