将AspDotNetStorefront与自定义ASP.net应用程序集成

Question

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

Answer 1

当你开始探索你的策略时，我给你的建议是了解整个系统是如何工作的。您会注意到，所有常规的Global.aspx Application_Start、Begin_Request方法都位于ASPDNSF.Core程序集中。你会在12000行的某个地方看到它们。这些命令会像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团队实现的源代码，因为许多应用程序行为是由支持的dlls控制的，并且管理界面在很大程度上依赖于在后端设置的用户应用程序设置，而不是从Web.config获取自定义参数。

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

一个重要的注意事项:如前所述，尽量不要修改存储过程、逻辑和打包到解决方案中的查询，因为当您试图更新系统时，您会发现自己已经走到了无法返回的地步。这在我的案例中发生了，我吸取了教训。我不得不接受ASPDNSF团队所做的工作，几乎完全修改了ML9多商店的原始代码库。

祝你好运：)