Golang交易API设计

tob*_*asH 5 architecture design-patterns transactions go clean-architecture

我正在尝试使用Go 遵循Clean Architecture。该应用程序是一个简单的图像管理应用程序。

我想知道如何最好地设计我的存储库层的接口。我不想将所有存储库方法组合到一个大接口中,就像我发现的一些示例一样,我认为在Go中,小接口通常是首选。我认为与管理映像有关的用例代码不需要知道存储库还可以存储用户。所以我想有UserReaderUserWriterImageReaderImageWriter。复杂之处在于代码需要是事务性的。事务管理属于“清洁体系结构”的范畴尚有争议,但我认为用例层需要能够控制事务。我认为,单笔交易属于业务规则,而不是技术细节。

现在的问题是,如何构造接口?

功能方法

因此,在这种方法中,我打开一个事务,运行提供的功能,并在没有错误的情况下提交。

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
}
Run Code Online (Sandbox Code Playgroud)

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

作为存储库交易

type ImageRepository interface {
    func Writer() ImageReadWriter
    func Reader() ImageReader
}
Run Code Online (Sandbox Code Playgroud)

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

一个实现可能看起来像这样:

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

不幸的是,如果我实现这样的事务方法:

func (r *BoltDBRepository) Writer() *BoltDBTransaction
func (r *BoltDBRepository) Reader() *BoltDBTransaction
Run Code Online (Sandbox Code Playgroud)

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

type ImageRepository struct { *BoltDBRepository }
func (ir *ImageRepository) Writer() usecase.ImageReadWriter
func (ir *ImageRepository) Reader() usecase.ImageReader
Run Code Online (Sandbox Code Playgroud)

交易即价值

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

type Transaction interface { 
    func Commit() error
}

type Repository interface {
    func BeginTransaction() (Transaction, error)
}
Run Code Online (Sandbox Code Playgroud)

存储库实现看起来像这样

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

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

问题:尽管这可行,但我必须在每个存储库方法的开头键入assert,这似乎有点乏味。

这些是我可以想到的方法。哪个最合适,或者有更好的解决方案?

Ari*_*cia 6

存储库是保存数据的位置的表示,也是一个架构元素。

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

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

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

type ImageRepository interface {
    func Keep(ImageData) error
    func Find(UUID) ImageData
}
Run Code Online (Sandbox Code Playgroud)

事务方法是一个实现细节,因此您可以创建 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(...)}
Run Code Online (Sandbox Code Playgroud)

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

例如,如果客户端引用了 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()
Run Code Online (Sandbox Code Playgroud)

这是干净、客观的,并且在洋葱架构、DDD 和 3 层架构(Martin Fowler)中工作得很好!

在洋葱架构中:

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

  • 嗯,这就是我们意见分歧的地方。我认为对于很多应用程序来说,您可能可以通过将事务包装在整个用例执行周围来实现,但在某些情况下需要更多控制,然后我相信这是业务层决定哪些操作需要是原子的。这似乎也是[鲍勃叔叔的观点(在页面上搜索“交易”)](http://blog.cleancoder.com/uncle-bob/2016/01/04/ALittleArchitecture.html)。 (2认同)