多层应用程序中的类的推荐命名约定是什么？

Question

我有类名/命名空间/控件的命名问题。

在我的商业库中，我有名为Shopping的名称空间。它包含以下类： 的ShoppingCartItem
我的购物
ShoppingCartManager

在我的ASP.net应用程序中，我想创建一个控件，以图形方式表示ShoppingCart实例的项目。通常情况下，我会调用那个控件ShoppingCart，但是另一个名为ShoppingCart的类？当然编译等也可以，但我认为它仍然很难看。我想我有一个问题，就是我把我的商业课程命名为他们应该代表的东西。因为当涉及到表示层时，我会将应该代表业务类的控件命名为相同的。

我想我可以添加像“View”这样的后缀，但我想做得对。

多层应用程序的推荐命名修改是什么？
我应该如何命名表示表示层中ShoppingCart项目的控件？

修改：相关问题： How should I name database wrapper object?

Answer 1

在MVC范例中，拥有Foo，FooView和FooController是相当普遍的。

您可能认为将它们粘贴在不同的层次结构中更容易（Shopping.Model.Cart，Shopping.View.Cart）。它在概念上很干净，但我认为这是不可读的。您可以在不同的命名空间中使用不同的名称（Shopping.View.CartView）。

一个好的IDE会让你移动/重命名，所以不值得花太多时间来担心选择完美的名称。更重要的是非常清楚你的建模和它的局限性。例如......

• Car是汽车的实例还是汽车的特定品牌/型号？摩托车是car吗？如果你要将它重命名为Vehicle，那么自行车是一辆车吗？
• Item是一种项目，项目实例或项目的quantity个实例吗？
• ShoppingCart只是一个项目/数量列表，还是有其他功能？它是否通过对数量求和来合并项目的重复项？
• 愿望清单是一种特殊的购物车（尚未购买的那种），还是别的东西？
• 你可以“保存”一个购物车并获得报价（这样你就可以打印出来，把它拿给你的老板，让它签字，然后再购买）？报价存储在哪里？

Answer 2

其他StackOverflow人员可能知道的更好，但据我所知，没有与分层架构相关的普遍接受或行业标准的命名约定。虽然我认为你走的正确：比特定的命名更多，选择一种方法并持续使用它将有助于使你的代码更易于维护。

Answer 3

您可以使用命名空间来分隔购物车UI和业务实体，例如：

• YourApp.Web.UI.ShoppingCart（您的购物车网页控件）
• YourApp.BusinessEntity.ShoppingCart（您的业务逻辑层中的购物车类）

当您创建/使用购物车对象时，初看起来对象是UI控件还是实体类可能并不明显，但是当您编写代码时，IDE（visual studio）将为您提供智能感知。将鼠标悬停在可以缓解问题的名称上时的工具提示。

或者，如果您真的想要放松眼睛阅读，可以在命名对象时使用前缀：

• YourApp.Web.UI.ShoppingCart uiShoppingCart;
• YourApp.BusinessEntity.ShoppingCart beShoppingCart;

Answer 4

在开始项目之前，您应该决定要使用的命名约定。 .NET Framework包含许多有关命名约定的建议，您可以在文档中的此位置找到VisualBasic®命名约定建议：

<强> MS-帮助：//MS.VSCC/MS.MSDNVS/vbcn7/html/vaconVBNamingRules.htm

决定并遵守一系列命名约定非常重要，而不是将自己局限于特定的命名约定。仔细考虑您使用的命名约定的影响是很重要的。例如，我仍然希望使用控件类型为控件名称添加前缀，因为我可以在代码编辑器中键入“txt”，按Ctrl + Space，然后获取表单上所有文本框控件的列表。

查看此 link以获取更详细的讨论。