我一直在使用规范模式来处理和包含c＃/ mvc应用程序中的业务逻辑。到现在为止还挺好。我确实有一个问题 - 因为我们将在堆上创建许多规范对象，这会以任何方式影响性能，比如创建帮助方法来处理业务逻辑吗？谢谢！
答案 0 :(得分：5)
我确实有一个问题 - 因为我们将在堆上创建许多规范对象，这会以任何方式影响性能，而不是创建帮助方法来处理业务逻辑吗？
当然它会影响性能，你编写的每一行代码和你所做的设计选择都会以某种方式影响性能。这个不太可能有意义，是你的应用程序的瓶颈或值得关注，因为这几乎肯定是过早优化的情况。现在，您应该专注于正确建模您的域，并编写非常清晰和可维护的代码。更专注于开发人员的工作效率而非机器生产力CPU周期很便宜，并且几乎无限供应。开发者周期并不便宜，而且供应不是无限的。
但只有通过分析，您才能知道它是否会影响您的应用程序在真实世界数据上的实际使用。我们不知道，也不知道，因为我们不了解您的域名，不了解您的用户，不知道您期望的性能等等。即使我们知道这些事情，我们仍然无法t给你一个强大的答案，你可以通过从架子上打扫一个分析器并看看你的应用程序实际上做了什么来给自己。
答案 1 :(得分：2)
因为我们将在堆上创建许多规范对象，这会以任何方式影响性能
大多数设计模式都牺牲了设计清洁度的一些开销 - 这也不例外。通常，规范添加的内存量非常小（通常是几个引用，就是这样）。此外，他们倾向于添加一些额外的方法调用与自定义逻辑。
话虽如此，我不会试图过早地优化它。这里的开销非常小，所以我非常怀疑它在任何现实世界的应用程序中都会引人注目。
答案 2 :(得分：0)
如果将NSpecifications库用作其GitHub页面中的示例，那么您将获得两个方面的好处：
这些规范中的大多数都只是存储在静态成员中，因此从堆中获取的开销不大
这些规范还使用编译后的表达式，以便可以多次重复使用它们，从而获得更好的性能
如果您使用ORM来查询同时使用堆的lambda表达式数据库，则此处的区别在于NSpecifications将这些表达式存储在Spec对象内，以便可以将其用于业务loginc和查询
在这里检查