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

Question

我的商店经常出现一些设计/建筑方面的问题。我个人说“我们”，而不是“我”。一些决定是在首次引入J2EE时做出的，因此有一些不好的设计选择，也有一些好的选择。


在Web环境中，如何使用过滤器。什么时候应该使用J2EE过滤器，什么时候不应该？是否可以有很多过滤器，特别是如果您有太多的逻辑。例如，在我们的身份验证过程中有很多逻辑。如果您是此用户，请转到此站点，否则请转到另一个。调试困难，因为一个URL路径可能最终呈现不同的目标页面。
用属性资源束文件来替换JSP文件中的值：Java社区中的共识似乎是使用包含标签和标题的束文件进行jsp解析。如果您使用多种不同的语言进行开发并根据语言环境切换标签值，那么我会看到好处。但是，如果您不使用多种语言怎么办？是否真的必须将JSP文件或其他模板文件中的每条静态文本放入属性文件中。再次，我们遇到调试问题，由于属性值键拼写错误或属性文件损坏，文本可能无法显示。另外，我们有一个过程，图形设计师将向我们发送html模板，然后将它们转换为jsp。然后删除静态文本，添加键，在属性文件中添加键/值等似乎更加令人困惑。


例如。 labels.properties文件可能包含Username：标签。那将被某些键替换并呈现给用户。


所有J2EE开发的单元测试-我们不鼓励单元测试。有人这样做，但我从未在使用大量单元测试的商店工作过。一旦放置好了，然后在紧迫的时间到了，我们就停止进行单元测试，然后过一会儿，单元测试就没用了，永远也不会编译。我所做的大部分开发工作都是与服务器，Web应用程序开发，数据库连接有关。我看到了单元测试可能很麻烦的地方，因为您需要一个针对单元测试的环境。我认为单元测试宣言鼓励开发人员不要实际连接到外部资源。但是似乎测试的主要部分应该连接到数据库并运行所有代码，而不仅仅是一个特定的单元。这就是我的问题，对于所有类型的开发（如您在面向CRUD的J2EE开发中所看到的），我们是否应该在所有情况下都编写单元测试？如果我们不编写单元测试，那么我们还可以使用其他哪些开发人员测试机制？


编辑：这里有一些有关这些主题的好资源。

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

Answer 1

重定向是一种根据角色处理不同页面的更简单方法。该过滤器可以仅用于身份验证，以将User对象和所有关联的Roles放入会话中。

正如詹姆斯·布莱克（James Black）所说，如果您有中央控制器，则可以省去将这种逻辑放入过滤器中的需要。为此，您需要将中央控制器映射到所有URL（或所有非静态URL）。然后，筛选器将“用户和角色”传递给中央控制器，该中央控制器决定将用户发送到哪里。如果用户尝试访问他没有权限的URL，则此控制器可以决定如何处理。

大多数主要的MVC Web框架都遵循这种模式，因此只需检查一下就可以更好地理解这一点。
我在这里也同意James的观点-您不必将所有内容都移到这里，但是将来可以使事情变得更简单。就个人而言，我认为您经常必须权衡这一点才能有效地与设计师合作。我经常投入基础架构和逻辑来使其正常工作，但是在与设计师合作时，用静态文本乱丢了我的模板。最后，返回并将所有静态文本提取到外部文件中。果然，那样发现了一些拼写错误！
测试-这是最大的测试。以我的经验，高度纪律的测试优先方法可以消除开发这些应用程序时的90％压力。但是单元测试还不够。

我使用了三种测试，如敏捷社区所指出的：


验收/功能测试-客户根据每项要求定义这些测试，并且直到它们全部通过之前我们才发货（请查看FitNesse，Selenium，Mercury）
集成测试-确保逻辑正确，并且不会跨层或与实际数据一起出现问题（请查看Cactus，DBUnit，Canoo WebTest）
单元测试-既定义了类的用法和期望，又保证可以迅速捕获重大更改（请参阅JUnit，TestNG）



因此，您会看到单元测试确实为开发人员带来了好处...如果我们中有五个人在从事该项目，那么不编写单元测试会导致两件事之一：


随着开发人员试图弄清楚如何使用（或有人破坏）彼此的类，必要的交流激增
由于“孤岛”，没有沟通，风险也增加了，只有一个开发人员接触代码，而公司完全依赖该开发人员


即使只是我一个人，也很容易忘记为什么六个月前我在课堂上放了这么少的特殊情况逻辑。然后，我破坏了自己的代码，不得不弄清楚怎么做……这是浪费时间，并且无济于事，无法减轻压力！另外，如果您强迫自己仔细考虑（并键入）类中每个重要功能的测试，并弄清楚如何隔离任何外部资源，以便可以通过模拟版本，那么您的设计将得到不可估量的改进。因此，无论如何，我倾向于首先进行测试。

可以说，最有用但最不常见的是自动验收测试。这是确保开发人员了解客户要求的内容。有时，这留给质量检查人员，我认为这很好，但是理想的情况是这些是开发过程中不可或缺的一部分。

它的工作方式是：针对每个需求，将测试计划转换为脚本，并添加到测试套件中。然后，您会看到它失败。然后，您编写代码以使其通过。因此，如果编码人员正在研究变更并准备检入，则他们必须进行全新构建并运行所有验收测试。如果有任何故障，请先修复，然后再进行检入。

“持续集成”只是使该步骤自动化的过程-当任何人签入代码时，单独的服务器签出代码并运行所有测试。如果有任何损坏，它会向最后一个开发人员发送垃圾邮件，直到他们修复为止。

我曾经向只有一名测试人员的团队咨询过。这个家伙整天都在手动完成测试计划。当发生变化时，无论多么微小，他都必须重新开始。我建立了一个电子表格，指示仅通过一个屏幕就有1600万条可能的路径，他们急忙为水星测试总监花了1万美元！现在，他制作了电子表格并自动执行了使用它们的测试计划，因此它们具有相当全面的回归测试，而无需不断增加QA时间要求。

一旦开始在应用程序的每个层上自动执行测试（特别是如果您首先进行测试），就会发生不寻常的事情。烦恼消失了！

因此，没有，这不是必需的。但是，如果您担心技术债务，本周末的大规模部署或担心在尝试快速更改以满足突然紧急的客户需求时是否要破坏事情，则可能需要更深入地调查测试-第一发展。