我应该只使用我已经创建的结构来建立应用程序,或者要创建一个带有所需字段的数据库?我认为这是你问题的关键。
从数据库开始
对我而言,在构建使用后端数据库的应用程序时,实体关系图非常重要。我在这里找到了一个相当不错的教程:http://www.sum-it.nl/cursus/dbdesign/english/index.php3,但你可以轻松找到适合你学习风格的教程。关键点是你正在尝试以某种方式捕捉问题领域(需要你的应用程序的那个真实世界),以便你的应用程序能够进行建模。一旦有了相关表的E-R图,就更容易理清细节。在SQL Server 2008(Express版本)中使用SQL Management Studio,您可以创建一些基本表并在那里构建E-R图,并让它为您生成关系。然后,你可以随意检查所用的SQL并进行细化。
就我个人而言,我总是从问题域入手,然后构建E-R图,再构建数据库。当我相信数据库反映了问题领域时,我开始构建C#应用程序。
从C#应用程序开始
但是,真正重要的是以有意义和有效的方式对现实世界进行建模。在你的情况下,你已经拥有了C#中创建的结构作为起点,可以使用它们作为起点来构建E-R图。如果你发现通过启动C#应用程序并构建反映它的数据库更容易,那也没问题。也许你已经有了一个帮助你有效捕捉问题领域的方法。无论你做什么,都是迭代的过程:构建C#代码可能会揭示底层数据库设计的问题,反之亦然。
制图-E-R还是UML?
我个人相信这整个业务如此复杂,以至于你真的需要一些图表。
- 使用E-R图可视化你的数据库
- 使用UML类图可视化你的C#应用程序
当你朝着一个工作的应用程序前进时,你会看到这两个图表开始相匹配或至少相互反映得非常紧密。在这两种情况下(实体或类),了解对象之间的关系将在查询数据库时非常重要,因为理解表之间的关系至关重要(特别是使用1对多关系来解决复杂的多对多关系)以及连接表的各种技术在查询中(INNER或OUTER join等)。无论你的C#应用程序有多聪明,你在某个时候都需要至少了解一些SQL语言的复杂性-如果可以参考E-R图,那就更容易了。
存储在哪里?
我的疑问是,通常我会将C#对象存储在字典或列表中,那么我是否应该直接从数据库中检索?
毫无疑问要存储在数据库中。例如,一个名为Family的C#类将具有属性FamilyName,并带有setter方法。如果您发现拼写错误并想更改名称,则setter方法将打开与数据库的连接,使用指定的家庭名称(可能还包括家庭ID)作为参数运行UPDATE查询,并相应地更新基础字段。检索数据将涉及运行SELECT查询等。
结论
进行一些教程,了解如何检查问题域,创建实体关系图并基于该图构建一组相关表。我相信这样做可以更容易地跟踪您构建的C#类与后端数据库的通信。
以下是有关家庭及其成员的简单E-R图示例:
开始时,您可能认为成员和家庭可以在一个表中,但随后您会发现这会导致很多重复,因此您需要将它们分开为具有一对多关系的家庭和成员表,但随后您会意识到,通过婚姻等方式,人们可以属于多个家庭,因此您需要创建多对多关系。我认为E-R图是解决此类复杂性的最佳场所。