Wpf 是先写类还是先通过DB创建实体模型？

我正在写我的第一个WPF应用程序。我还安装了EntityFramework（EF）4.1。这两方面我都是新手。我还通过参考示例代码学习编写MVVM类

我想知道是应该首先为Model、View和ViewModel设计类，还是首先设计数据库模式并使用EF自动生成类。建议采用哪种方法

---

我在VisualStudio解决方案中创建了三个文件夹，即：Model、View和ViewModel。我将向这些文件夹中添加相应的类。还有什么建议吗？

Entity Framework 4.1中的主要功能是代码优先开发风格，我建议您在开始使用新应用程序时使用此功能，并且不必使用现有的数据库架构

这意味着您首先要设计模型类，使用数据注释或Fluent API指定一些映射细节，然后让EF生成数据库和数据库模式。在许多情况下，您根本不需要数据注释或Fluent API，因为EF 4.1遵循一组映射约定，这意味着EF可以从类和属性的命名约定推断出必要的数据库模式。这使得在许多情况下模型到数据库的映射非常容易

在这两种方法中—数据库优先或代码优先—您必须记住，您希望在这两个世界之间建立一个工作映射。您可以创建不能或不容易映射到关系数据库模式的模型类，另一方面，您可以创建难以或不可能映射到模型类的数据库模式。因此，熟悉如何创建可以映射到EF4.1数据库的模型类的示例是有意义的

如果您想从数据库模式或模型开始（可能取决于您是否有强大的数据库管理员，他们可能不喜欢自动生成的数据库模式），这在某种程度上取决于您的品味。但在我看来，代码首先会加快开发速度

编辑

对于您关于项目组织的问题：在一个（“WPF-UI”）项目中拥有视图和视图模型是可以的，因为它们无论如何都是紧密相连的。把模型和所有EF的东西放在这个项目中也没有错。但将Model和EF移动到解决方案中一个单独的项目（类库）中有很好的理由。它允许您更轻松地使用其他访问模型和数据库的应用程序（例如，简单的工具程序（控制台应用程序）来测试某些东西或在数据库上执行某些工作）

---

许多人也会投票赞成将模型和EF分成不同的项目（一个“域或业务逻辑项目”和一个“EF持久层项目”或其他项目）。但既然你说你正在开始，这可能是太多的分层抽象，很快就会失控。如果您想要更好地分离关注点，您可以在稍后的阶段进行重构。

我通常在需求研究之后首先设计数据库模式。如果新样式建议首先使用代码，那么我还需要在纸上设计基本模式，以便正确地设计类。@RPK：我认为代码优先背后的思想是，在开发过程中，您不必太担心数据库模式，而只考虑实体类以及它们之间的关系。重点是“ORM”中的“O”。如果您觉得从DB模式开始更合适，那么一个好的方法可能是在DB中创建初始模式，然后创建模型类（两个步骤：从DB创建模型（EDMX），然后是T4 DbContext Generator），然后首先进行代码微调和扩展。