0

我有一个会发展的基础应用程序。现在 UI 包括 BLL。DAL 是一个为其目的服务的独立库。

我现在没有时间做所有事情，所以我想绕过有助于解耦的模式（IoC，DI，正如我在这里提出的那样）。

我想创建我的 BLL 并直接参考 DAL。这将使我有机会开始创建我现在需要的单独 UI。

我的问题是我能做到吗？我现在可以专注于创建我的 3 层并逐渐应用设计模式以使我的代码更好吗？

添加信息：

我有足够的时间，因为我的第一个应用程序不会在第二个应用程序的开发过程中使用。所以我将有时间优化我的编码结构。我能做些什么来尽可能有效地将 UI 拆分为 UI + BLL 的问题。我的想法是，我将在 BLL 中移动 DAL 初始化并将 BLL 初始化放入 UI。还有什么我可以做的，它会在以后应用 IoC/DI 时对我有更多帮助吗？

4

3 回答 3

2

快速获得工作产品通常是最重要的事情，因此有意识地决定跳过一些工程实践可能是正确的决定。

但是，您需要确保做出正确的权衡。重构不是免费的，需要计划好处理技术债务。

一旦最终用户看到您的初始版本，阻力最小的路径通常是继续添加功能而不是重新访问初始设计决策。

换句话说，一旦 1.0 版本发布，您将很难说服管理层您需要花费大量的人工日在后台重新工作，而不会为客户带来可察觉的变化或利益。

如果不了解您的应用程序的详细信息或要求，就不可能给出具体的建议。一般来说，尽管花一些时间预先考虑设计比尝试以某种方式进入开发阶段要快和简单几个数量级。

于 2012-12-12T09:13:25.787 回答
1

我非常喜欢这种情况下的“债务”隐喻。您推动交付第一个工作版本并在代码质量和工程最佳实践方面妥协的速度越快，实施任何新的变更请求的时间就越长，也就越难。

由您决定您想要获得多少“债务”。认为从头开始创建产品是展示您的品质的独特机会，如果您在一个月内交付它但需要五个月来实施一些简单的更改请求，您的信誉和声誉将受到影响，他们将取代您。

于 2012-12-12T10:02:07.907 回答
1

您可以使用这种结构设置“穷人的依赖注入”：

public class MyEndClass
{
    private readonly IDependency dependency;

    public MyEndClass(IDependency dependency)
    {
        this.dependency = dependency;
    }

    // temporary constructor until we introduce IoC
    public MyEndClass() : this(new Dependency())
    {
    }
}
于 2012-12-12T10:24:28.917 回答