我可能会负责将vb6应用程序移植到c#。此应用程序是与access数据库交互的windows应用程序。数据访问被封装在基本业务对象中。基本上,一个类对应一个表。现有的vb6业务对象通过DAO对数据库进行读写。我以前写过几次DAL和ORM,但它们都只针对SQL Server。这将需要以access和sql server为目标。在以前的项目中,我会将SQL字符串放在业务对象的私有部分,并可能会将冗余的sql代码(如连接、创建命令)移到一个公共基类中以减少代码。
这一次,我考虑将SQL字符串写入.settings文件或其他键/值类型的文本文件。然后,我将编写一个sql实用程序来编辑该文件,并允许我运行和测试参数化查询。这些查询将在业务对象中按名称引用,而不是将sql嵌入到代码中。
我知道一种标准的方法是为每个目标数据库创建一个DAL,并具有要使用的DAL的配置状态。我真的不想为每个数据库创建两个DAL类。如果我只是通过键名引用正确的查询,并且具有正确的连接类型,那么代码似乎会更少。
那么,你们在做这样的事情吗?您将如何或曾经如何处理此问题?什么是最适合你的?
谢谢!
发布于 2009-02-23 06:28:18
嗯,有很多选择-所以这真的取决于你最迫切的需求是什么:-)
一种方法可能是在VS解决方案中将SQL语句创建为文本文件,并在“构建操作”中将它们标记为“嵌入式资源”。这样,SQL就包含在生成的程序集中,并且可以在运行时使用.NET框架的ResourceManifestStream从其中检索:
private string LoadSQLStatement(string statementName)
{
string sqlStatement = string.Empty;
string namespacePart = "ConsoleApplication1";
string resourceName = namespacePart + "." + statementName;
using(Stream stm = Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName))
{
if (stm != null)
{
sqlStatement = new StreamReader(stm).ReadToEnd();
}
}
return sqlStatement;
}
您需要将"ConsoleApplication1“替换为您的实际名称空间,即sql语句文件所在的名称空间。您需要通过完全限定名称来引用它们。然后,您可以使用以下行加载您的SQL语句:
string mySQLStatement = LoadSQLStatement("MySQLStatement.sql");
然而,这使得查询相当“静态”,例如,你不能在运行时配置和更改它们-它们被直接烘焙到编译后的二进制位中。但另一方面,在VS中,您可以将C#程序代码和SQL语句很好地分离开来。
如果您需要能够在运行时调整和更改它们,我会将它们放入一个单独的SQL表中,该表包含一个关键字和实际的SQL查询作为字段。然后,您可以根据需要检索它们并执行它们。由于它们在数据库表中,您还可以随意更改、修复和修改它们-甚至在运行时-而不必重新部署整个应用程序。
Marc
发布于 2009-02-23 07:52:28
当我真的需要它时,我将查询放入单独的*.sql文件中,然后将它们包含到Resources.resx中。其中有一个“文件”部分,允许您包含嵌入式资源文件。
在此之后,我可以使用生成的Resources.MyQuery属性,它既保证了资源的存在,又使我不必编写自定义的资源加载方法。
发布于 2009-02-23 13:22:59
如果我必须同时为SQL和Access创建应用程序,我会使用一些IDAL接口,即具有公共功能实现和从DALCommon继承的独立DALSql和DALAccess的DALCommon,以及一些特定的东西,如异常、事务处理、安全性等。
我过去常常将存储过程名称或查询保存在资源文件中。
https://stackoverflow.com/questions/576571
复制相似问题