1

我想将 AspDotNetStorefront 与自定义 ASP.net 应用程序集成。关于如何去做的任何想法？任何帮助都感激不尽。

4

1 回答 1

1

当你开始探索你的策略时，我给你的建议是熟悉整个系统的工作原理。您会注意到所有正常的 Global.aspx Application_Start、Begin_Request 方法都位于 ASPDNSF.Core 程序集中。您会在第 12000 行（ish）的某处看到它们。这些像往常一样被解雇，就像 Global.aspx

    public static void Custom_SessionEnd_Logic(Object sender, EventArgs e)
    {
        // put any custom session end logic you need here...
        // do not change this routine unless you know exactly what you are doing
    }
    public static void Custom_Application_Error(Object sender, EventArgs e)
    {
        // put any custom application error logic you need here...
        // do not change this routine unless you know exactly what you are doing
    }
    public static void Custom_Application_EndRequest_Logic(Object sender, EventArgs e)
    {
        // put any custom application end request logic you need here...
        // do not change this routine unless you know exactly what you are doing
    }

遵循执行流程将带您以一种非传统的方式来编程 asp.net 网站。ASPDOTNETStorefront 没有很好地分离关注点，因此您经常会看到样式代码直接注入到 ASPDNSF.controls.dll 程序集中。如果您的业务逻辑要求需要不支持开箱即用的功能，这可能会非常令人沮丧。但就像 .NET 中的任何东西一样，一切皆有可能。

我建议您在 Web 解决方案中创建一个自定义文件夹，并从那里创建您的自定义用户控件，并根据需要在站点周围部署它们。尽量不要修改太多由 ASPDNSF 团队实现的源代码，因为许多应用程序行为由支持的 dll 控制，并且管理界面严重依赖后端设置的用户应用程序设置，而不是自定义来自 Web.config 的参数。

自 2009 年以来，我一直在与 ASPDNSF 合作，我可以告诉您，将当前成功的平台迁移到网站需要时间，但这是可行的。XML 模板功能强大但有点过时。

一个重要的注意事项：如前所述，尽量不要修改打包到解决方案中的存储过程、逻辑和查询，因为在寻求更新系统时，您会发现自己越过了不归路。这发生在我的案例中，我吸取了教训。我被迫接受 ASPDNSF 团队所做的工作，几乎完全修改了 ML9 多商店的原始代码库。

祝你好运：）

于 2012-12-07T23:34:09.447 回答