Spring示例：学生项目，spring示例项目

Spring示例：学生项目，spring示例项目

最近，我正在开发一个关于博客的示例项目，采用专注用户界面的方式（the UI-inward approache）。基于REST接口对前端开发者非常重要这一想法，我决定从REST服务入手自顶向下开发，而非从业务层或持久层自底向上开发。（显然这个只使用于小团队，大型团队可以并行开发）

开发步骤如下：

1. 创建一个”hello,world” Webapp，可以部署或者运行集成测试。包含一个静态页面，显示Webapp正在运行。
2. 实现REST服务端，返回各种请求结果，比如获取一个返回404对象，请求一个空列表等。
3. 实现REST客户端，用作集成测试。
4. 实现整体测试，创建检验实例并执行每个REST调用。
5. 选择性地创建一个简单的Dev Webapp调用REST服务器。这个Webapp可以被一个后台dev轻松地调用，而不是直接使用REST调用。类似的，Webapp也可以直接和业务或者持久层交互。
6. 实现业务层存根（Stub），只依据REST客户端要求提供接口，并提供一个最小的子数据库来存放当前REST服务器存根。
7. 实现业务层单元测试。
8. 借用业务层调用替换REST服务器存根。
9. 实现持久层存根。
10. 实现持久层单元和集成测试。
11. 借用持久层调用替换业务层存根。
12. 实现准确地持久层。

有两种实现方法：第一种是广度优先，即先实现所有REST应用程序接口，接下来实现
所有的业务层存根等等。这样的优点是FE devs能自由地去做任何事情，缺点是需要花费大量的时间去发现集成中的各种问题。

第二种是深入优先，先实所有的REST应用程序接口现。即使所有的东西都实现了存根，接下来会完成某一个概念的全部实现。比如创建、编辑、删除REST调用或者列出一个流程的全部实现。优点是会较快地发现集成问题，缺点是即使是一个简单的概念，实际操作中却是非常复杂。

学生项目：业务实体

“学生项目”是一个类注册app。业务实体：

学期：学术术语，比如2014年春季学期。

课程：一门具体的课程，比如计算机科学101。

课程是一个永无休止的实体。1994年的微积分101和30十年后的微积分没有本质的差别。这种模式在一些快速发展的领域会有一些例外。比如，虽然重要的概念（计算机科学现代概念介绍）不会变化，但是1994年的计算机科学101与2014年的计算机科学101却有着很大的不同。

章节：一门很受欢迎课程的特定实例。一个特定章节只能发生在某一个学期中，但是每个学期可以包含多个受欢迎的课程章节。另外，对一个用于多个章节的课程可以存在于多个学期（这个模式无需考虑实验室、讨论组等）。存在一个章节分布多个学期，以及多个章节归属一门课程的关系。

教室：校园内一个教室实例在某个时间只能为一个章节占用。简单地说，
教室E3-105, MWF, 10-11Term S14，而不是明确地列出这个学期每天教室的安排。教室和学期存在n:1的关系，教室和章节也存在n:1关系，但是教室不能章节有1:n的关系（但是教室可以和章节可以有n:1关系，即可能一个章节拥有两个或者三个教室）。

辅导员：教授或者研究生。每个章节至少有一名辅导员，每个辅导员能教授零到多个章节。辅导员和章节存在n:n关系。

学生：某个班级的注册学生。学生和章节存在n:n关系。这种模型基于这样的事实，即辅导员常常是学生本身，比如研究生。年级生不包含在模型中却和辅导员类似。

学生项目：业务操作

这里可以快速列出一些显而易见的业务操作：

• 添加学期。
• 添加或者编辑课程（由于历史原因，不能删除一门课程）。
• 添加或者编辑章节。
• 除去某个章节。这个操作会影响到辅导员和学生。
• 列出某门课程的章节。
• 列出所有的可能但不包括任何章节。
• 添加或者编辑某个教室。
• 移出教室，比如由于比较的维护，会影响章节。
• 分配某个教室给某个章节或者从章节解除分配的教室。
• 列出分配给某个章节的教室。
• 列出可用的教室。
• 给某个章节安排一名辅导员，或者将安排辅导某个章节的辅导员取消。
• 列出安排辅导某个章节的辅导员。
• 列出可用的辅导员。
• 从一个章节中注册或者注销一位学生。
• 列出已注册的学生。

学生项目：接下来的开发安排

我会继续发布文章讨论这个项目的其它方面。我会按照计划实现，并博客中发布。考虑到其他因素，所以可能会出现一点的反复。

原文链接： invariantproperties 翻译： Wld5.com - 乔永琪
译文链接： http://www.wld5.com/8828.html
[ 转载请保留原文出处、译者和译文链接。]