DataAccess 项目中类的命名约定是什么?

发布于 2024-08-16 03:49:24 字数 200 浏览 2 评论 0原文

我通常将 Business 项目中的类命名为 Manager.cs,例如 BaseManager.cs、CommentsManager.cs、ProfileManager.cs 等...

如何命名 DataAccess 项目中的类?您将其称为 CommentsDA、CommentsDB 还是什么?

只是好奇...顺便说一句,我正在使用 .NET C#。

I usually name by classes in the Business project as Manager.cs, like BaseManager.cs, CommentsManager.cs, ProfileManager.cs, etc...

How do you name your classes in the DataAccess project? Do you call it CommentsDA, CommentsDB, or what?

Just curious...BTW, I'm using .NET C#.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

假扮的天使 2024-08-23 03:49:24

软件层之间的命名约定

我曾经为您所询问的每种软件层分离类命名约定。然而,在 .NET 世界中,当意识到每一层都是它自己的程序集,并且程序集通常可以替换为实现相同接口的程序集时,我发现命名空间是最重要/最有效的更改,并删除了特定于类的前缀和后缀,大多数情况下。

例如,我曾经有 Customer (业务)和 CustomerDAL (数据访问层)

..并且在我最近的项目中经常改变分别...

带有 ICustomer 接口的 Com.Example.ProjectName.Business.CustomerCom.Example.ProjectName.Data.Customer在它们之间使用,而不是直接访问目标项目中的任何特定类。

低内聚改变了类命名的重要性

通常,通过实现类后缀或前缀,您会尝试防止紧密耦合的程序集之间的命名冲突

然而,通常建议通过接口来松散耦合组件;副作用是您不再直接使用具体的类名。否则,通过使用紧密耦合的程序集,您还可以将它们组合成一个程序集,因为它们直接相互依赖,并且单独程序集的好处会减少。

有时我的软件采用更具描述性的方法,例如 CustomerCustomerData 类,我意识到这是使用后缀,但目的是为了自然流畅,而不是防止命名冲突是因为我的界面无论如何都位于它们之间。

简而言之,低内聚性使得在项目的任何层中应该/可以/将相对于彼此命名哪些类的问题变得毫无意义。并且因为您已经拥有用于业务和数据职责的单独程序集,您必须隐含地希望存在低内聚力。因此,根据问题的概念,我在应用程序设计方面的回答是客观上没有类后缀或前缀更好

C# 代码示例

为了提供有用的代码示例,我添加了以下 C# 框架来显示我倾向于的类命名策略(或者缺少策略可能更准确)。

注意:此示例在某些方面并不完整,但显示了类命名如何在程序集之间无关紧要(即使它是相同的类名)的概念,因为它们是使用接口分隔的。

Business.dll - 业务层程序集

参考 Shared.dll 程序集。

namespace Com.Examle.MyProject.Business {
    using Com.Example.MyProject.Shared; // for ICustomer

    class Customer {
        // Reference obtained to an ICustomer implementation (not shown).
        // Composition of the data customer, just for illustration purposes
        ICustomer _cust;

        // From business, a data access usage example:
        public void GetData() {
            _cust.SaveToDataSource();
        }
    }
}

业务使用 ICustomer,而不是硬连线到 Data.dll 程序集。

Shared.dll - 共享程序集 - 常见类型被引用到业务和数据程序集中。

// This is the only required link between business and data assemblies. 
// Business is shielded from Data concrete class names and vice-versa. 
namespace Com.Example.MyProject.Shared {
    public interface ICustomer {
        void SaveToDataSource();
    }
}

Data.dll - 数据访问层

参考 Shared.dll 程序集。

namespace Com.Example.MyProject.Data {
    using Com.Example.MyProject.Shared; // for ICustomer

    class Customer : ICustomer { // implement ICustomer - other assemblies can too
        public void SaveToDataSource() {
            // logic to save data to the data source
        }
    }

}

Naming Conventions between Software Layers

I used to separate class naming conventions for each kind of software layer like you're asking about. However in the .NET world upon realizing each layer is it's own assembly, and assemblies are often replaceable with assemblies implementing same interface/s, I found the namespace to be the most important/effective change, and dropped class-specific prefixes and suffixes, for the most part.

For example, I used to have Customer (business) and CustomerDAL (data access layer)

.. and that has often changed in my recent projects to, respectively ...

Com.Example.ProjectName.Business.Customer and Com.Example.ProjectName.Data.Customer with an ICustomer interface being used between them instead of directly accessing any specific class in the target project.

Class Naming Importance is Changed by Low Cohesion

Usually, by implementing a class suffix or prefix you're trying to prevent against naming conflicts between tightly coupled assemblies.

However it's usually recommended to have loosely coupled assemblies by way of interfaces; a side effect is you don't use the concrete class name directly anymore. Otherwise by using tightly-coupled assemblies you might as well combine them into one assembly because they rely on one another directly and the benefit of separate assemblies is diminished.

Sometimes my software takes a more descriptive approach like Customer and CustomerData classes, and I realize this is using a suffix, but the intention is for natural flow and not to prevent against naming conflicts because my interface sits between them regardless.

In a nutshell, low cohesion renders the question moot of what classes should/could/would be named in any layer of the project relative to one another. And because you already have separate assemblies for business and data responsibilities, you must implicitly want low cohesion to be present. So my answer in context of application design is no class suffix or prefix is objectively better according to the concept of the question.

C# Code Example

For the sake of a useful code example, I'm including the following C# skeleton to show the class naming policy I gravitate toward (or lack of policy might be more accurate).

Note: This example is incomplete in some ways but shows the concept of how class naming doesn't matter between assemblies (even if it's the same class name) because they are separated using interfaces.

Business.dll - Business layer assembly

Reference Shared.dll assembly.

namespace Com.Examle.MyProject.Business {
    using Com.Example.MyProject.Shared; // for ICustomer

    class Customer {
        // Reference obtained to an ICustomer implementation (not shown).
        // Composition of the data customer, just for illustration purposes
        ICustomer _cust;

        // From business, a data access usage example:
        public void GetData() {
            _cust.SaveToDataSource();
        }
    }
}

Business is using ICustomer instead of being hard-wired to the Data.dll assembly.

Shared.dll - Shared assembly - Common types are referenced into both business and data assemblies.

// This is the only required link between business and data assemblies. 
// Business is shielded from Data concrete class names and vice-versa. 
namespace Com.Example.MyProject.Shared {
    public interface ICustomer {
        void SaveToDataSource();
    }
}

Data.dll - Data access layer

Reference Shared.dll assembly.

namespace Com.Example.MyProject.Data {
    using Com.Example.MyProject.Shared; // for ICustomer

    class Customer : ICustomer { // implement ICustomer - other assemblies can too
        public void SaveToDataSource() {
            // logic to save data to the data source
        }
    }

}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文