开始一个新项目 - 我从哪里开始？
我将开始一个自己的项目，该项目将是 ASP.NET MVC + Fluent NHibernate。我想尽可能地使用测试优先的方法。那么，我具体从哪里开始呢？数据库架构？领域模型？将域模型类映射到数据库？
I am going to start a project of my own, which will be ASP.NET MVC + Fluent NHibernate. I want to use test-first approach as much as I can. So, where exactly do I start from? Database schema? Domain model? Mapping domain model classes to the database?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您在编写测试方面没有什么经验，那么从领域模型（或 UI 下方的更高级别）开始是最简单的。当您使用 TDD 驱动领域模型的设计时，您就会知道数据库模式需要是什么样的。推迟在系统中引入数据库可能是件好事，因为处理数据库模式迁移会给开发增加一些开销。这也将带来更好的设计，因为这样域模型将更好地与数据库层解耦。
如果您擅长编写测试和 TDD，那么从端到端测试开始（在这种情况下，它们将针对 Web UI 编写）并生成涉及所有架构部分的一小部分功能可能会有所帮助系统的（如 GOOS 中建议的）。换句话说，创建一个行走骨架。这种方法的好处是（1）您将能够从一开始就处理和解决集成问题，（2）当使用端到端测试来驱动设计时，它可以帮助您避免实施多余的部分，以及（3）编写端到端测试的困难迫使您改进架构并添加监控挂钩，这对于监控生产中的系统也可能有用。 （仍然需要集中的单元测试，因为它们在类级别提供设计压力，而且它们运行得更快，从而提供更快的反馈。）
我在 可集成性设计。
If you have little experience in writing tests, it's the easiest to start from the domain model (or a higher level just below the UI). When you have driven the design of the domain model with TDD, then you will know that what the database schema needs to be like. It may be good to postpone introducing a database to the system, because dealing with database schema migration will add some overhead to the development. And that will also lead to a better design, because then the domain model will be better decoupled from the database layer.
If you are skilled in writing tests and in TDD, it may be beneficial to start from an end-to-end test (in this case they would be written against the web UI) and produce a thin slice of functionality which touches all architectural parts of the system (as recommended in GOOS). In other words, create a walking skeleton. The benefits from this approach are that (1) you will be able to tackle and solve integration problems right at the start, (2) when the end-to-end tests are used to drive the design, it can help you to avoid implementing superfluous parts, and (3) the difficulties of writing the end-to-end tests pressure you to improve the architecture and add monitoring hooks, which may also be useful in monitoring the system in production. (Focused unit test will still be needed, because they provide design pressure at the class level, plus they run faster and thus provide faster feedback.)
I've written more about this latter approach at Design for Integrability.
需求收集。
Requirements gathering.
从应用程序的模拟/原型（例如 Balsamiq Mocks）开始，然后编写视图，一路模拟控制器，然后编写控制器逻辑，一路模拟 DAO/存储库。当您开始编写 DAO/存储库时，您将对所需的域对象有一个很好的了解。淘汰那些并使用 Fluent Nhibernate 来构建您的数据库。
至少这是我尝试做事的方式。
Start with a mock/prototype (e.g. Balsamiq Mocks) of the application, then writre the views, mocking controllers as you go along, then write the controller logic, mocking the DAO/Repositorys along the way. By the time you start writing your DAO/Repositories, you'll have a good idea of your your required domain objects. Knock those out and use Fluent Nhibernate to build your database.
At least that's they way I'm trying to do things.
我推荐您 S#arp Architecture 项目，该项目使用最佳实践结合：
您还可以安装 S#arp arch。 Visual Studio IDE 的模板。
I recommend you S#arp Architecture Project that uses best practices combining:
You can also install S#arp arch. template for Visual Studio IDE.