我一直在尝试使用规格模式来处理和包含我们c# / mvc应用程序中的业务逻辑。到目前为止还不错。但是我有一个问题 - 因为我们将在堆上创建许多规格对象，这是否会影响性能，与创建帮助器方法来处理业务逻辑相比呢？谢谢！
规格模式与性能
7
- rh1200
1
1在.NET中，堆分配并不是什么可怕的事情，因为a）堆压缩意味着分配通常相当便宜，b）垃圾回收意味着堆分配风险较小（因为您不必那么仔细地跟踪对象生命周期）。 - Dan Bryant
3个回答
5
我确实有一个问题-既然我们将在堆上创建许多规范对象，那么与创建处理业务逻辑的帮助方法相比，这是否会以任何方式影响性能？
当然，它会影响性能。你编写的每一行代码和设计选择都会以某种方式影响性能。这个问题不太可能对应用程序造成意义重大的瓶颈或值得关注，几乎可以肯定是过早优化的情况。如今，您应该专注于正确建模您的域，并编写极其清晰和易于维护的代码。更关注开发人员的生产力而不是机器的生产力。CPU周期很便宜，几乎是无限的。开发人员周期不便宜，也不是无限的。
但是只有您才知道它是否会通过分析对真实世界数据的应用产生影响。我们不知道，也无法知道，因为我们不知道您的领域，不知道您的用户，不知道您期望的性能等等。即使我们知道这些事情，我们仍然不能像您自己通过拿起分析器并查看您的应用程序实际操作时那样给出强大的答案。
当然，它会影响性能。你编写的每一行代码和设计选择都会以某种方式影响性能。这个问题不太可能对应用程序造成意义重大的瓶颈或值得关注，几乎可以肯定是过早优化的情况。如今，您应该专注于正确建模您的域，并编写极其清晰和易于维护的代码。更关注开发人员的生产力而不是机器的生产力。CPU周期很便宜，几乎是无限的。开发人员周期不便宜，也不是无限的。
但是只有您才知道它是否会通过分析对真实世界数据的应用产生影响。我们不知道，也无法知道，因为我们不知道您的领域，不知道您的用户，不知道您期望的性能等等。即使我们知道这些事情，我们仍然不能像您自己通过拿起分析器并查看您的应用程序实际操作时那样给出强大的答案。
- jason
1
谢谢，我同意你对性能的许多因素的评论。由于我正在尝试包含我们的业务逻辑，我发现规范模式很有用（可重用的业务逻辑，易于单元测试），但是我们的负责人并不认同，他认为使用帮助方法可以用更少的代码和更少的对象实现相同的结果。 - rh1200
2
由于我们将在堆上创建许多规范对象，这会影响性能吗？
大多数设计模式都为设计的清晰性而付出了一些开销-这也不例外。通常，规范所添加的内存量非常小（通常只有几个引用），此外，与自定义逻辑相比，它们往往会增加几个额外的方法调用。
话虽如此，我不会试图过早地对其进行优化。这里的开销非常小，因此我非常怀疑在任何实际应用程序中都不会注意到它。
大多数设计模式都为设计的清晰性而付出了一些开销-这也不例外。通常，规范所添加的内存量非常小（通常只有几个引用），此外，与自定义逻辑相比，它们往往会增加几个额外的方法调用。
话虽如此，我不会试图过早地对其进行优化。这里的开销非常小，因此我非常怀疑在任何实际应用程序中都不会注意到它。
- Reed Copsey
1
应该对堆遍历表示关注吗？因为规范可能以任何顺序和数量存储在堆中。 - RBZ
0
如果您只是像NSpecifications库GitHub页面中的示例一样使用它，那么您将从两个世界中获得好处：
- 大多数这些规范仅存储在静态成员中，因此不会占用太多堆空间。 - 这些规范还使用编译表达式，以便可以重复使用多次并具有更好的性能。
如果您正在使用ORM使用lambda表达式查询数据库，那也会使用堆，但这里的区别在于NSpecifications将这些表达式存储在Spec对象中，以便可以重复使用于业务逻辑和查询。
请在此处查看。
- 大多数这些规范仅存储在静态成员中，因此不会占用太多堆空间。 - 这些规范还使用编译表达式，以便可以重复使用多次并具有更好的性能。
如果您正在使用ORM使用lambda表达式查询数据库，那也会使用堆，但这里的区别在于NSpecifications将这些表达式存储在Spec对象中，以便可以重复使用于业务逻辑和查询。
请在此处查看。
- jnicolau
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接