问题标签 [cake-pattern]

我正在尝试使用 Cake 模式为 SearchService 创建一个抽象。这是我目前拥有的：

假设我有一个 DbSearchServiceComponent 和 LuceneSearchServiceComponent 如下：

相似地...

我对上述代码段的问题是

我已经在服务实现中初始化了 lucene 客户端和 db 客户端的实例。

理想情况下，我想“混合”一个“客户端”基本类型，它可以是 Db 客户端或 Lucene 客户端，但我对如何在此处注入多态客户端类型感到非常困惑。

有人能指出我如何能够重构代码，以便我可以将不同版本的客户端注入到我的 SearchService 特征的实现中吗？

我目前正在烘烤我的第一个蛋糕图案，所以请多多包涵。

我拿了我的工作单体应用程序，并将其切割成功能层。剪切看起来很干净，但导致两个层依赖于隐式 ActorSystem。

我试图像这样解决这种依赖关系：

...同样适用于 LayerX

我的装配类看起来像：

其中 ActorSystemProvider 只是实例化了actor系统。

这不起作用，因为ActorSystem当依赖关系被解析并且 val 被实例化时不存在，从而导致 NPE。这看起来也很丑陋，我相信必须有一种更好/更简单的方法来处理它。

在使用蛋糕模式时，我应该如何处理层之间的共享隐式依赖关系，就像ActorSystem在这种情况下一样？

谢谢

我正在尝试使用蛋糕模式进行依赖注入，如下所示：

但编译器抱怨RequiresFoo.this.type#Foo不符合预期的类型this.type#Foo。

所以问题是：是否可以在AlsoNeedsFoo内部创建一个对象RequiresFoo以便依赖注入正常工作？

通常会检查 Specs2 加糖的 Mockito 验证，并在适当的时候通过测试。但是在某些情况下，它们会被忽略。

通常，此测试验证会按预期失败，因为 myApp 至少调用了一次 myService。

（注意WithApplication是一个玩！框架的东西）

然而，由于我已经将蛋糕模式特征融入到我的组件中，所以我的测试看起来像这样。

MockRegistry 看起来像这样

我的 Cake 图案测试永远不会失败。我可以将其更改为任何内容，它们都会被忽略。

但是，通过直接调用 java 方法来替换加糖的 mockito 步骤，它在适当的时候确实会失败。

因此，似乎涉及测试方法的特征似乎已经正确混淆了 Mockito。

为什么每个人都使用这种形式的定义：

取而代之的是：

第二种方法似乎更通用，因为 UserService 特征未绑定到特定的组件实例。

有什么我想念的吗？

编辑：通过“更通用”，我的意思是你可以做这样的事情（将两个具有不同 impl. 的蛋糕混合成一个）：

如果您将 UserService 定义为嵌套特征，那么您将得到一个异常：类型不匹配；找到：Program.Cake1.UserService，需要：Program.UserService

I've been playing with the cake pattern and there's something I don't fully understand.

Given the following common code:

the following way of mixing them works

But the following does not

with error:

Shouldn't we be able to "push" dependencies up in the hierarchy if we know that they will be common for all subclasses?

Shouldn't the compiler allow for Controller to have dependencies, as long as it's not instantiated without resolving them?

I'm developing a Play! 2.2 application in Scala with Slick 2.0 and I'm now tackling the data access aspect, trying to use the Cake Pattern. It seems promising but I really feel like I need to write a huge bunch of classes/traits/objects just to achieve something really simple. So I could use some light on this.

Taking a very simple example with a User concept, the way I understand it is we should have:

So far it's totally reasonable. Now we add a "Cake Patternable" UserRepository:

Then we have a UserService:

Now we mix all of this in an object :

1. Is UserRepository really useful? I could write findByName as a custom query in Users slick object.

2. Let's say I have another set of classes like this for Customer, and I need to use some UserService features in it.

Should I do:

or

目前我正在使用 guice 在控制器内连接我的 UserService，例如：

我的用户服务看起来像：

如果我想放弃 guice 作为依赖项并使用 cake 模式，代码会是什么样子，我将如何将其集成到 Play 中以便我可以在我的控制器中使用此服务？

看过一些关于Scala的蛋糕模式的文章，基本明白了。以下是我从本文中复制的一些示例代码：

成分：

组合它们的对象：

如果我在一个简单的项目中，我想让它更简单。代码将如下所示：

将它们组合起来：

我的问题是，我的代码仍然可以被视为“依赖注入”吗？

1. UserService我在的构造函数中声明了依赖项
2. 我将它们与不同环境中的对象结合起来

但我没有提供一些特征作为“组件”。

我试图将我对蛋糕模式的理解转换为简单的 scala 代码，发现它没有编译。有人可以看看下面的代码并告诉我我理解模式的方式有什么问题吗？我读了这篇文章并尝试了类似的东西（http://www.cakesolutions.net/teamblogs/2011/12/19/cake-pattern-in-depth）

在下面的代码中println("This is " + userServiceComponent.whatCalc1) //> This is ()- 我期待它打印This is ScifiCalc Calc但它的打印This is ()

代码：-