在包含经典 ASP 和 ASP.Net 1.1 代码的项目中管理连接字符串的最佳方法是什么?
-
05-07-2019 - |
题
我继承了一个项目,它主要是一个经典 ASP 应用程序;然而,该应用程序中混杂着一些 ASP.net 页面。某些 ASP.net 页面是 1.1,并且不使用代码隐藏模型。
经典的 ASP 页面有许多 /include 目录,其中有一个用于数据库连接的文件。ASP.Net 页面在其代码中硬编码了连接字符串。
我正在尝试清理这些混乱的连接字符串,以便更轻松地跨开发环境进行管理。
有没有人对我如何有效地做到这一点有任何建议,这对于经典 ASP 和 ASP.Net 页面都适用?
谢谢
解决方案
将web.config文件放在asp经典网站的根目录下。没有代码的ASP.net页面(假设没有任何虚拟目录/应用程序)将使用该web.config文件。您可以在其中放置连接字符串。你最终可能会有两组字符串,但这比其他字符串更好。如果你真的想,你可以编写一些asp经典代码来读取该配置文件。
其他提示
这种方式专注于将连接字符串文件与webroot隔离,以用于源代码版本控制系统(如svn)。
文件:
c:\inetpub\config\config.xml
c:\inetpub\wwwroot\global.asa
c:\inetpub\wwwroot\onInit.asp
config.xml中:
<?xml version="1.0" encoding="utf-8" ?>
<root>
<database
ip="XXXX"
catalog="XXXX"
id="XXXX"
password="XXXX"
/>
</root>
的global.asa:
<script runat="Server" language="VBScript">
Sub Application_OnStart()
server.execute("/onInit.asp")
End Sub
Sub Application_OnEnd()
End Sub
</script>
onInit.asp:
<%
dim xmlDoc, xmlPath, objNodes
set xmlDoc = server.CreateObject("microsoft.xmldom")
xmlDoc.async = false
xmlPath = Server.MapPath("/")
xmlPath = left(xmlPath, inStrRev(xmlPath, "\")) & "config\config.xml"
xmlDoc.load xmlPath
set objNodes = xmlDoc.selectNodes("//database")
application("connectionString") = "Provider=SQLOLEDB.1;Persist Security Info=True;"_
& "Data Source=" & objNodes.item(0).getAttribute("ip") & ";"_
& "Initial Catalog=" & objNodes.item(0).getAttribute("catalog") & ";"_
& "User ID=" & objNodes.item(0).getAttribute("id") & ";"_
& "Password=" & objNodes.item(0).getAttribute("password")
set objNodes = nothing
set xmlDoc = nothing
%>
唔。我想我不是唯一一个需要清理这种混乱的人。
我没有 非常 对您有用的答案,但这是我们提出的策略。它超出了您的问题,但希望它能回答您尚未想到要问的问题。您面前的任务非常艰巨,我想在整个过程中为您提供尽可能多的提示,而不仅仅是连接字符串。
- 彻底重组我们的源代码
- 彻底重组我们网络上的文件结构
- 修复代码 因为我们需要修改它, ,而不是尝试将其作为一个大项目一次性完成。
- 将经典 ASP 转换为 ASP.NET 成为既定目标 (并通过更快的开发/维护节省劳动力来证明该项目的合理性,从而获得了我们经理的认可。)
- 创建并记录了用于存储连接字符串、通用文件、共享 CSS 文件等的标准。
- 作为重组的一部分,我们有一个全局共享文件夹,我们可以从任何项目中引用它。其中包含在多个单独项目网站等中使用的通用图像、CSS 等。
- 我们还指定每个网站都有一个公共文件夹,其中包含 CSS、脚本和 img 子文件夹,以便我们处理的每个项目都是一致的。
- 一旦我们完成了第一个 Web 应用程序的重写,我们就创建了一个项目模板,使启动新的网站项目变得非常简单。
作为我们所做的所有工作的副作用,我们只需使用转换向导就可以非常轻松地在 Visual Studio 中进行两次升级。从 VS 2003 到 VS 2005,再到 VS2008 都是轻松的。
此外,我们对源代码控制的选择是根据我们想要如何解决问题而做出的。我们使用了 TFS,但受到 TFS 项目和 VS 解决方案之间关系的限制。我们发现使用 Subversion 比 TFS 具有更大的灵活性,因此我们能够以比 TFS 更易于管理的方式布置源代码目录结构。