我正在尝试使用Go 遵循Clean Architecture。该应用程序是一个简单的图像管理应用程序。
我想知道如何最好地设计我的存储库层的接口。我不想将所有存储库方法组合到一个大接口中,就像我发现的一些示例一样,我认为在Go中,小接口通常是首选。我认为与管理映像有关的用例代码不需要知道存储库还可以存储用户。所以我想有UserReader,UserWriter和ImageReader和ImageWriter。复杂之处在于代码需要是事务性的。事务管理属于“清洁体系结构”的范畴尚有争议,但我认为用例层需要能够控制事务。我认为,单笔交易属于业务规则,而不是技术细节。
现在的问题是,如何构造接口?
因此,在这种方法中,我打开一个事务,运行提供的功能,并在没有错误的情况下提交。
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 …Run Code Online (Sandbox Code Playgroud) architecture design-patterns transactions go clean-architecture