设计一些继承的SQL类
本文关键字：SQL 继承 | 更新日期: 2023-09-27 18:30:07
我用C#编程已经有一段时间了，但我从来都不擅长设计模式或应用OOP，我现在正试图改变这一点。
我遇到的问题是，我把所有的SQL语句都放在一个名为"SQLConn"的类中，但现在我不想把它分解成子类。
在我的应用程序中，有一个数据库和其中两个表"规则"answers"日志"。
我的想法是为每个表（我在应用程序中使用的表）创建一个子类，并将所有方法移动到该类并打开一个新的连接。
因此，如果我有一个名为SQLLog和SQLRules的子类，它们是SQLConn的子类。当用户将新规则插入应用程序时，它会创建一个SQLConn.SQLRules的新实例并运行"InsertRule（）"，它还会创建一个SQL Conn.SQLLog的新实例，并运行"InsertLog（"user inserted rule X"）"，这是一个好主意吗？
根据这篇文章，是用一个连接执行多个sql命令更好，还是每次都重新连接更好？连接池将被激活，所以应该不会有太大的性能差异。
因此，总结一下这个问题：这样设计SQL类好吗*父类：SQLConn-包含连接信息*子类：SQLLog-包含"InsertLog（）"方法*子类：SQLRules-包含"InsertRule（）"方法
如果我在应用程序的一部分中同时需要SQLRules和SQLLog，我是否应该创建两个实例，一个是SQLLog，另一个是SQL Rules，并分别调用它的方法？这个设计好吗？
谨致问候，托马斯
如果您有两个独立的类，它们有自己的连接，如果您使用的是具有相同连接字符串的适当版本的SQL Server，则连接应该是池。
就设计而言，将数据库和应用程序代码分离是一种很好的做法。也就是说，将数据库中的SQL代码作为SQL数据库中的存储过程（除非是动态SQL或LINQ-SQL或类似的东西）。关于存储过程的使用存在一些争论，但我认为这在您的情况下是合适的。
然后，您可以在C#代码中使用调用这些存储过程的方法，而不必在代码中使用SQL代码作为字符串。这通常更容易维护，因为您可以在SSMS而不是Visual Studio中处理SQL代码。
如果做不到这一点，至少可以将SQL代码放在项目中自己的脚本文件中。
这听起来并不是一个坏主意，根据德米特定律拆分功能是使项目更具可测试性和可维护性的好方法。