Java/J2EE标准实践和设计选择

Question

我有几个设计/建筑问题总是出现在我们的商店里.我说"我们的",而不是"我".在J2EE首次引入时做出了一些决定,因此有一些糟糕的设计选择和一些好的选择.

1. 在Web环境中,如何使用过滤器.什么时候应该使用J2EE过滤器,什么时候不应该使用？是否有可能有许多过滤器,特别是如果你有太多的逻辑.例如,我们的身份验证过程中有很多逻辑.如果您是此用户,请转到此站点,如果没有,请转到另一个站点.调试很困难,因为一个URL路径最终可能会呈现不同的目标页面.

2. JSP文件中替换值的属性资源包文件:似乎Java社区的共识是使用包含jsp解析的标签和标题的包文件.如果您使用多种不同的语言进行开发并根据区域设置切换标签值,我可以看到好处.但是如果你不使用多种语言呢？是不是必须将JSP文件或其他模板文件中的每个静态文本放入属性文件中.再次,我们遇到调试问题,由于拼写错误的属性值键或损坏的属性文件,文本可能不会显示.此外,我们有一个过程,图形设计师将向我们发送html模板,然后我们将它们转换为jsp.然后删除静态文本,添加密钥,在属性文件中添加键/值等似乎更令人困惑.

例如,labels.properties文件可能包含Username:标签.它被一些键替换并呈现给用户.

3. 所有J2EE开发的单元测试 - 我们不鼓励单元测试.有些人这样做,但我从未在使用大量单元测试的商店工作过.一旦到位,然后当关键时刻到来时,我们停止进行单元测试,然后一段时间后单元测试无用且无法编译.我所做的大部分开发都是关于服务器,Web应用程序开发,数据库连接.我看到单元测试可能很麻烦,因为你需要一个单元测试的环境.我认为单元测试清单鼓励开发人员不要实际连接到外部源.但似乎测试的主要部分应该是连接到数据库并运行所有代码,而不仅仅是特定的单元.所以这是我的问题,对于所有类型的开发(就像你在CRUD导向的J2EE开发中看到的那样)我们应该在所有情况下编写单元测试吗？如果我们不编写单元测试,我们可以使用哪些其他开发人员测试机制？

编辑:以下是其中一些主题的一些很好的资源.

http://www.ibm.com/developerworks/java/library/j-diag1105.html

Answer 1

1. 重定向是一种根据角色处理不同页面的简单方法.过滤器可以简单地用于身份验证,以将User对象和任何关联的角色放入会话中.

   正如James Black所说,如果你有一个中央控制器,你可以避免将这个逻辑放在过滤器中.为此,您需要将中央控制器映射到所有URL(或所有非静态URL).然后,过滤器将用户和角色传递给中央控制器,中央控制器决定将用户发送到何处.如果用户试图访问他没有权限的URL,则该控制器可以决定如何处理它.

   大多数主要的MVC Web框架都遵循这种模式,因此请检查它们以便更好地理解这一点.

2. 我也同意詹姆斯的观点- 你不必将所有东西都移到那里,但它可以使将来更简单.就个人而言,我认为你经常需要交换这一个,以便与设计师有效地合作.我经常把基础设施​​和逻辑放在工作中,但在与设计师合作时,我会用静态文本填充我的模板.最后,返回并将所有静态文本拉出到外部文件中.果然,发现了一些拼写错误!

3. 测试 - 这是最重要的.根据我的经验,高度严谨的测试优先方法可以消除开发这些应用程序90%的压力.但单元测试还不够.

   我使用了三种测试,如敏捷社区所示:

   • 验收/功能测试 - 客户根据每个要求定义这些并且我们不发货直到它们全部通过(看看FitNesse,Selenium,Mercury)
   • 集成测试 - 确保逻辑正确并且不会跨层或使用实际数据出现问题(查看Cactus,DBUnit,Canoo WebTest)
   • 单元测试 - 既定义了类的用法和期望,又保证快速捕获重大变化(查看JUnit,TestNG)

所以你看到单元测试真的是为了开发人员的利益......如果我们有五个人正在研究这个项目,那么编写单元测试不会导致以下两种情况之一:

• 随着开发人员试图找出如何使用(或者有人如何破坏)彼此的类,必要的沟通爆炸式增长
• 没有沟通和由于"孤岛"而增加的风险 - 只有一个开发人员接触代码并且公司完全依赖于开发人员的领域

即使只是我,也很容易忘记为什么我在六个月前将这一小段特殊逻辑逻辑放入课堂.然后我打破了我自己的代码,不得不弄清楚如何......这是浪费大量时间,并没有减少我的压力水平!此外,如果您强迫自己仔细考虑(并键入)类中每个重要函数的测试,并弄清楚如何隔离任何外部资源以便传入模拟版本,那么您的设计将无法估量地提高.所以无论如何我都倾向于先测试.

可以说最有用但最不经常的是自动验收测试.这可以确保开发人员了解客户的要求.有时这留给QA,我认为这很好,但理想情况是这些是开发过程中不可或缺的一部分.

这种方式的工作方式是:对于每个要求,测试计划都会转换为添加到测试套件中的脚本.然后你看它失败了.然后你编写代码让它通过.因此,如果编码人员正在进行更改并准备签入,他们必须进行干净的构建并运行所有验收测试.如果有任何失败,请在办理登机手续之前修复.

"持续集成"只是自动执行此步骤的过程 - 当任何人检查代码时,单独的服务器会检出代码并运行所有测试.如果有任何损坏,它会阻止最后一个开发人员检查,直到它们被修复.

我曾经咨询过一个有一个测试人员的团队.这家伙整天都在手动完成测试计划.当发生变化时,无论多么微小,他都必须重新开始.我为它们构建了一个电子表格,表明只有一个屏幕就有超过1600万条可能的路径,他们匆匆忙忙地为Mercury Test Director筹集了1万美元!现在,他制作电子表格并自动执行使用它们的测试计划,因此他们可以进行非常彻底的回归测试,而不会增加QA时间要求.

一旦你开始在应用程序的每一层自动化测试(特别是如果你先测试工作),就会发生一件非常重要的事情.忧虑消失了!

所以,不,没有必要.但是如果你发现自己担心技术债务,本周末的大规模部署,或者你是否会在试图快速改变以满足突然紧急的客户要求时打破局面,你可能想要更深入地调查测试 - 第一次发展.