代码重复 C# 的最佳实践

发布于 2024-07-14 17:19:42 字数 399 浏览 6 评论 0原文

我正在尝试以减少/避免代码重复的方式构建我的代码，并且我遇到了一个有趣的问题。每次我的代码调用存储过程时，我都需要传递存储过程常用的一些变量：例如用户名、域、server_ip 和 client_ip。这些都来自 HttpRequest 对象或 system.environment 对象。

由于这些被传递到每个存储过程，我最初的想法是创建一个实用程序类，它是一个数据库包装器，并且每次都会初始化并传递这些，所以我不必在我的代码中这样做。问题是 c# 类（在 App_Code 文件夹内）看不到 Httprequest 对象。当然，我可以将其作为参数传递给包装器，但这将破坏创建包装器的整个目的。我在这里错过了什么吗？

我意识到每次调用存储过程时重复 4 行代码并不是什么大问题，但我宁愿在早期阶段消除代码重复。

原文

分享到QQ

分享到微博

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

发布评论

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

只有一腔孤勇 2024-07-21 17:19:43

尝试 System.Web.HttpContext.Current.Request 获取当前请求。

回复收藏 0 原文

不奢求什么 2024-07-21 17:19:43

你可能正走下滑坡。 DRY 的要点是不要在多个地方重复业务逻辑，因为需求的更改会导致需要在多个类似的地方更改代码。如果这 4 行是上下文相关的，那么您不必仅仅因为这 4 行是相同的就进行重构。您还通过引用 httprequest 破坏了封装，因为您正在使用全局变量。作为您班级的使用者，我必须了解实现细节，我只能从 Web 应用程序中调用您。

话虽这么说，如果您考虑到这一点并且仍然想继续，这里是此类信息的另一种选择。创建一个包含所需属性的自定义 SecurityPrincipal（实现 IPrincipal）并将其附加到线程。当用户登录时填写它们，然后您可以在请求期间的任何地方访问它。您的调用者仍然需要确保这已完成，但至少它不是特定于平台的。

否则，为了获得最佳封装，请将具有所需属性的类传递到需要使用这些属性的每个对象的构造函数中。

回复收藏 0 原文

怂人 2024-07-21 17:19:42

将数据层设置为从基类继承，该基类包含这些值的 4 个属性。使公共构造函数需要这 4 个属性。

然后在业务层中执行类似的操作 - 基类在构造函数中使用这 4 个属性。

然后 UI 执行 new BusObj( Request["username"], ... ).method()

在数据层中，您可以使用一个方法来构建具有这 4 个属性的 SQLParameter 数组，然后每个方法都可以向大批。

回复收藏 0 原文

信仰 2024-07-21 17:19:42

作为一般规则，无论编程语言如何，如果您可以眯起眼睛并且代码看起来相同，您应该从中创建一个函数/方法/消息并传递参数。

一旦你有需要大量参数的方法（4 是一个很好的经验法则，但它绝对是具体情况的基础），那么就需要考虑另一件事，是时候让该方法采用对象作为参数了而不是单独的参数。 99.99999999999999999999% 的时间这样的对象应该是不可变的（没有可写的实例变量）。

回复收藏 0 原文

oО清风挽发oО 2024-07-21 17:19:42

HttpContext.Current 与您在 HttpRequest 中找到的信息类似，更重要的是在 App_Code 中可用。

回复收藏 0 原文

梦开始←不甜 2024-07-21 17:19:42

这是一个你可能喜欢也可能不喜欢的奇怪想法：定义一个“配置文件”类和一个函数，该函数将配置文件扩展为采用公共参数的函数的参数。

class P {
    readonly string name;
    readonly string domain;
    public P(string name, string domain) {
        this.name = name; this.domain = domain;
    }
    public void inject(Action<string, string> f) {
        f(p.arg1, p.arg2);
    }
    public T inject<T>(Func<string, string, T> f) {
        return f(p.arg1, p.arg2);
    }
}

在具有 AddressOf 运算符的 VB.net 中，它可能会工作得更好。我会非常谨慎地使用这种类型的东西，因为你很容易损害可读性和封装性。

Here's a weird idea you may or may not like: define a 'profile' class and a function that expands the profile into the arguments of functions taking the common arguments.

class P {
    readonly string name;
    readonly string domain;
    public P(string name, string domain) {
        this.name = name; this.domain = domain;
    }
    public void inject(Action<string, string> f) {
        f(p.arg1, p.arg2);
    }
    public T inject<T>(Func<string, string, T> f) {
        return f(p.arg1, p.arg2);
    }
}

It might work better in VB.net where you have the AddressOf operator. I would be really cautious using this type of thing, because you could easily damage readability and encapsulation.

回复收藏 0 原文