如何将服务重构为API、存储库和缓存(.NET)？

Question

我正在做一个.NET项目，它最初是一个原型，现在必须进行扩展。我们有带有实体框架的ASP.NET MVC堆栈(代码优先)。

我想知道如何使用API、处理缓存的存储库等将其扩展到“适当的体系结构”。

注意:我不是在寻找一个讨论(这并不意味着在这个网站上发生)，但这只是如何解决这通常。

今日

形势：

我们有一个网站、服务项目、模型项目和数据库项目：

因此，在实践中，我们的网站使用服务，模型和数据库组装。服务返回我们的模型对象，它从Context.cs上的直接使用中检索这些对象。

因此，在实践中，我们可以在服务项目中调用CustomerService，这是从模型项目的ICustomerService派生出来的。这将直接调用数据库项目中的Context，然后从Model返回一个Customer对象。

今天最有经验的问题：

1. 业务逻辑、缓存逻辑和数据库逻辑不是分开的，而是服务中的一大堆
2. 不可能轻易地使用新的缓存、数据库或类似的。
3. DB对象存在许多不一致的问题，直接与EntityFramework连接/分离。

My thinking:

我正在考虑一种类似这样的架构：

其中：

• API将有自己的视图模型，这些模型与API的使用者所期望的参考资料一样工作
• 服务层将允许Repository处理所有数据库活动。
• 我们将能够用缓存来装饰模型对象。

，但这给我留下了很多问题：

• 这个体系结构甚至有一点意义吗？
• 哪些物体会被注入到哪里？服务会将存储库注入到从CustomerRepository派生出来的IRepository吗？缓存是如何实际完成/调用的？
• 这给我留下了一个对象的3种表示形式。模型、API视图模型和网站视图模型--似乎花费了很多时间。
• 我在哪里能找到一些对我有帮助的例子呢？

Answer 1

这个体系结构甚至有一点意义吗？

在我看来是合理的。您已经正确地确定了您需要的层，以及它们中的哪些行为属于它们。

哪些物体会被注入到哪里？服务会将存储库注入到从CustomerRepository派生出来的IRepository吗？缓存是如何实际完成/调用的？

我很确定你说的是依赖注入？如果是的话，服务层将注入回购层，api层将注入服务层。几乎所有对系统执行业务逻辑的依赖都应该被注入，这样您就可以进行单元测试。

如果您还没有直接的数据库缓存，那么我建议您从直接数据库缓存开始，如果仍然在生产中演示了性能问题，则可能添加更高级别的缓存。如果您的API是RESTful，则可以更进一步，使用缓存代理(如squid )和正确设置缓存头。这是否方便将取决于您的堆栈-例如，NHibernate内置了L2缓存支持。

这给我留下了一个对象的3种表示形式。模型、API视图模型和网站视图模型--似乎花费了很多时间。

是啊。权衡的是更多的时间来获得更多的灵活性。除了您看到的附件问题之外，绑定到所有三个层的单个表示可能会非常有限。例如，您不能决定让API发布一个由两个或多个数据库表组成的单一资源。对表示的任何更改都会影响整个应用程序，这可能是不可取的。您可能还会发现，随着时间的推移，特定于层的信息会渗透到您的表示中，这将增加不属于其他层的依赖关系。

我在哪里能找到一些对我有帮助的例子呢？

超出范围了。-(谷歌是你的朋友？试试像.net n-tier example这样的东西。或者，如果您更喜欢真正的代码，您可以使用github，看看上面是否有什么东西可以处理。