我为一个项目创建了一个单独的类,它包含数据库的所有访问代码。 这是一个很好的做法,假设这个类不包含任何逻辑,或者我应该使用几个类?如果是,我应该如何划分我的代码?我使用C#.Net。
答案 0 :(得分:2)
实际上在MVC框架的概念下,最好为数据库访问创建一个不同的类,为逻辑创建单独的类,为视图创建单独的类。
如果你在假设它不包含任何逻辑的情况下编写一个单独的数据库访问类,那么你做得很好。
在Agile Developement中,有一个名为Database Encapsulation Layers的术语。
数据库封装层从业务代码中隐藏数据库的实现细节,包括其物理模式。实际上,该层为您的业务对象提供了持久性服务 - 从数据源读取数据,向其写入数据和从中删除数据的能力。理想情况下,您的业务对象应该对它们如何被持久化一无所知,它只会发生。数据库封装层并不神奇,它们不是学术理论;数据库封装层通常被大型和小型应用程序以及简单和复杂应用程序使用。数据库封装层是每个敏捷软件开发人员应该了解并准备使用的重要技术。
有效的数据库封装层将带来以下好处:
- >它减少了对象模式与数据模式之间的耦合,从而提高了发展任何一个模式的能力。
- >它在一个地方实现所有与数据库相关的代码。
- >它简化了应用程序员的工作。
- >它允许应用程序员专注于业务问题,而敏捷DBA可以专注于数据库。
- >它为您提供了实现面向数据的业务规则和逻辑的通用位置。
- >它利用了特定的数据库功能,提高了应用程序性能。
希望这有帮助。
答案 1 :(得分:1)
如果您的数据库非常小,比如只有几个表,您可以在一个类中编写所有查询。否则我会建议每个实体/表一类。例如,StudentDao.class将只关注对数据库表“STUDENT”的查询,而TeacherDao.class将只包含对表“TEACHER”的查询。如果你要实现一个复杂的业务逻辑,你可能想要一个服务类,一起编织StudentDao和TeacherDao。
答案 2 :(得分:1)
除非您的数据访问非常简单,否则可能不是。
您可能不需要自己编写此代码。看看一些对象关系映射工具。 NHibernate是一种流行的.Net解决方案。 http://en.wikipedia.org/wiki/NHibernate
如果您确实想自己编写,请在此区域中查找设计模式,例如数据传输对象模式。 http://martinfowler.com/eaaCatalog/dataTransferObject.html
答案 3 :(得分:0)
这些是访问数据库时的一些建议。
1。)始终将数据库访问参数保留在属性文件中。使用处理程序获取这些数据。因为当您更改数据库时,您无需更改代码,只需在属性文件中进行更改即可。 - 所以在这里你需要一个处理程序类。
2。)永远不要创建一个执行所有动作的单一类(神级)。根据意图将您的行为分散到不同的类中。例如,将所有读取行为保留在一个类中,将行为写入另一个类......等等。
3。)您可以创建一个处理连接创建和汇集内容的类... 希望这会有所帮助。