Question

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

Answer 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多店的原始代码库。

祝你好运：）

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

1 个答案: