【问题标题】:How to architect this ASP.NET n-tier solution?如何构建这个 ASP.NET n 层解决方案?
【发布时间】:2009-04-08 14:21:01
【问题描述】:

我在尝试布局我的 VS 解决方案时遇到问题,我想要一些建议。

目前,我的解决方案布局类似于以下项目:-

Foo.Models
Foo.Repositories
Foo.Services
Foo.Web (an ASP.NET MVC application)

我的网站 (Foo.Web) 调用 Foo.Services 命名空间上的各种方法。这里的想法是Services 处理所有业务逻辑Model 命名空间只是 POCO 对象。 Repositories 命名空间是不言自明的。

构造函数依赖注入与接口处理什么层需要什么组件的黑魔法。

问题:我想添加一些 Windows 工作流基础 (WWF) 代码 解决方案,但将此 WWF 代码放入 相同的 Foo.Services.dll。

为此,我需要创建另一个Workflow 类型的项目。此工作流具有调用 Foo.Services 方法的活动。因此,我的网站现在必须调用服务方法或工作流方法来做事。

我希望网站只调用Services 命名空间来做事。

毕竟,服务是 UI 和业务逻辑之间的主要接口,IMO。我在技术上使用 WWF 的事实对于在 IUI 前端进行编码的人来说不应该是一个问题。

由于工作流dll调用Services dll中的方法,Services dll由于循环依赖无法调用Workflow中的方法。

我也无法将所有工作流代码移入服务 dll,因为服务 dll 需要是一些特殊的项目类型(Windows 工作流类型)。

所以..我不知道该怎么办?

我怎样才能让消费者只引用商业内容的服务命名空间,而我在 WWF 中暗示这些商业内容的事实对消费者是隐藏的?

我是否需要创建一个 WWF 项目并将我的所有服务代码移入其中,扔掉旧的服务项目?这样做听起来不太可重用。如果我决定不使用 WWF 来处理某些管道操作并使用其他东西会发生什么?

这里有一些代码可以帮助解释。

HomeController.cs
public ActionResult Index()
{
   // StockService was created using constructor dependency injection.
   var viewData = _stockService.GetStocks(StockType.MostPopular);
   return (viewData)
}

StockService.cs
public class StockService : IStockService
{
    public IEnumerable<Stock> GetStocks(StockType stockType)
    {
        // Dependency Injection defines if the Pipeline is WWF
        // or something else (eg. plain ole functions).
        var stocks = _stockPipeline.GetStocks(stockType);

        // Cache result.

        // Update repostiory. (example of calling the repository)
        _sqlRepostiory.SaveSomeRandomData("Jon Skeet Was Here.");

        return stocks. // Returns a POCO.
    }
}

谢谢大家。

【问题讨论】:

    标签: asp.net-mvc visual-studio-2008 architecture workflow-foundation n-tier-architecture


    【解决方案1】:

    你看过 Rob Connery 的 MVC Storefront/Kona 项目吗?他在做a very similar thing with WF,他的项目是laid out in a somewhat similar way。你正在做的事情可能是good guidance。我知道他在设计集成时确实与一些 Workflow Foundation 专家合作。

    【讨论】:

    • 肯定有。这就是我的东西的基础。我对他从 SF -> Kona 的变化有点困惑。
    【解决方案2】:

    一种可能的解决方案是添加一个“应用程序”层

    Application ---> Services
                        ^
                        |
                \--> Workflow
    

    并从 UI 调用应用层。当然,在大多数情况下,应用层只会将调用转发到服务或工作流。

    【讨论】:

      【解决方案3】:

      仅供参考 - 可以修改非工作流项目以允许添加工作流类。详情here.

      【讨论】:

      • 因此,即使我可以将类库项目更改为 WF 项目 .. 这真的从架构的角度回答了我的问题吗?可以,但我应该这样做吗?
      猜你喜欢
      • 2013-08-06
      • 2011-11-16
      • 1970-01-01
      • 1970-01-01
      • 2023-04-05
      • 2015-07-27
      • 2011-12-24
      • 1970-01-01
      • 2011-10-23
      相关资源
      最近更新 更多