Struts is a framework for using within a J2EE web application that tries to provide web applications with an MVC-pattern based approach to coding. It includes some added utilities for form data validation etc. It is an open source project, and has been quite good at solving that particular piece of the web application puzzle, and is limited to only solving that particular piece.
ATG (ATG Dynamo), on the other hand, is an application platform - a solution and a framework - for building data- and content- driven web applications - largely for commerce and publishing. At the framework level, it is a Java based application platform for hosting web-based applications, as well as RMI accessible business components, with an ORM layer, a component container, an MVC framework, and a set of tag libraries for JSP. The component framework (The Nucleus) is a lightweight container for managing the life cycle and dependency binding (dependency injection) of Java component objects (beans). In that sense it is somewhat similar to the Spring bean container, and is the core of the ATG framework - all other services and frameworks are hosted within it. The ORM layer framework (Repositories) maps objects to and from relational databases (as you would expect). But it can also handles mapping with LDAP, XML and file system data ources using the same consistent data access API. The JSP tags for binding form elements on a page to values on business objects etc. are more elegant and cleaner than the form binding tags in any other framework I have seen. The mechanism of writing your own tag library equivalents (Droplets) is much more consistent with the Servlet API than standard J2EE tags.
The MVC framework (the basic Form handler pattern) is somewhat similar to Struts Form and Action classes - but provides a much more basic framework that Struts does. Out of the box, and at the level at which most developers work, the ATG model is page-driven not controller-driven. Internally, it is certainly controller-driven with a pipeline approach to chaining dispatchers and controllers.
In addition, the framework at the basic level gives you an RMI container, distributed caching, distributed locking and distributed singletons, distributed events and messaging, a task scheduler, a rules engine and a mechanism for defining business workflows with custom actions and outcomes, a graphical editor for business workflows, support for versioned data, support for roles and rights, logging and auditing - all out of the box, and all using very coherent and consistent APIs
Then at the solution level, you have the components and the APIs for dealing with user profiling, identity management and personalization, content authoring, versioning and publishing, content search, product catalogs for tangible and intangible goods, product search and guided navigation, pricing, tax calculation, promotions, shopping carts, gift lists and wish lists, payment types, shipping methods, order tracking, customer relationship management etc.
The extension points and integration points to ATG are usually very well designed and quite well documented. They support integration with pretty much anyone who is anyone in the e-commerce and publishing space for things like authoring and content management, identity management and security, product catalogs, search and guided navigation etc. Also, almost all areas of the framework are extensible and plug-gable so you can write your own components to enhance or replace the ones out of the box.
It does not really make much sense to compare the two. However, given your question, I imagine what you are really interested in is the MVC part of ATG
For MVC, Struts gives you more than ATG does (but then Spring MVC gives you even more than Struts does). However, you tend to get bogged down in the mechanics of the framework far more with Struts than with ATG.
Personally, I think that ATG's form-handler based model is more elegant, cleaner and easier to work with than most other web MVC frameworks I have seen, and the APIs are more consistent with the Servlet APIs.
Bear in mind, also, that most 'web-MVC' frameworks are not like true MVC (i.e. the pattern used for GUI programming in Smalltalk or even Java Swing etc.). Neither Struts nor ATG provide (as designed) true MVC - though ATG actually comes closer. There is a lot of confusion about terminology.
For example,
the Model in true MVC is not your data model nor your domain model objects. It is the model that represents all the data in a view. If that happens to be a domain model object then well and good - but more often than not, you will find that you need a different set of view or form objects. Also, the model is responsible for keeping itself updated - it is the Model that interacts with business services lower down. ATG tends to fuse the model and the controller into one component - the form-handler. Struts tends to keep the view data model distinct (the form object), but does not encourage its use as a model in the true MVC sense - it is not the form object that interacts with other business services to keep itself updated.
the Controller in MVC is not your business controller. A controller in MVC is a conduit between the view and the model. It reacts to changes in the view, or to actions performed on the view, and instructs the model to update itself accordingly. In Struts the Controller they talk about is not an MVC controller at all - it is really a dispatcher. A lot of the code that belongs in a controller ends up in your Action class. But the way Struts is designed, the Action class is really meant to do what a Model does.
the View in MVC should be populated by the model - it is a push mechanism with the model updating the view, not a pull mechanism with the view querying the model. In most web-MVC frameworks, the view (usually a JSP) pulls state from the model in order to display itself. This is particularly the case with ATG's page-driven approach. If you find that data is being fetched while your page is rendering it means something is wrong with your MVC design.
In Struts, the function of the MVC Controller is spread across the Struts controller and the Action, while the function of the MVC Model is spread across the Form object and the Action.
In ATG, the function of the MVC Controller and the MVC Model is all in the Form-handler
Having said that, due to the request-response nature of HTTP, the function of a Controller in a web-MVC framework is quite limited. With web applications, we tend to get a completely updated view on form submission rather than lots of small changes (e.g. each key press or mouse click, or each changed input field) as we would with a rich UI framework. The use of AJAX is changing that - and we have to think much more about implementing MVC correctly.
Remember, MVC is a design pattern - i.e. it is a design-time principle to be used when designing the GUI aspect of applications. Struts, and ATG are frameworks - i.e. they are classes and objects to be extended, implemented or configured when building your application. A framework cannot enforce the use of a design pattern - it can merely encourage it. Choosing to use a particular framework will not make you design your ciode better - at most it may encourage a certain discipline.
If you design your MVC well, it will not make a huge difference whether you use Struts classes or ATG classes to implement it. Likewise, if you design your MVC badly, hoping that your choice of framework will make up for your shortfalls, it will not make a huge difference whether you use Struts or ATG. If you understand and work with the design principles, you will find it very easy to switch back and forth between frameworks.
The best code will be that which adheres to a good design principle (say, true MVC) in the abstract, and implements it (realizes it) using the right tools available in the chosen framework in the way they are intended to be used.
Coming back to your question;
If you are working on an ATG project, you should use the frameworks that ATG provides. It is certainly possible to shoehorn Struts into an ATG application - I have done this myself many years ago - but it is far more effort than it is worth - and you are giving up a lot of what ATG provides out of the box in terms of object life-cycle management, form data binding etc..
If you are about to start work on a new project and have a choice of frameworks to use - I would personally recommend an open source application server (like JBoss) and the Spring Framework - it gives you the best of what ATG and Struts provide. It has a Nucleus-like component container (the Application Context), it integrates with all good ORM solutions (such as Hibernate) and includes an MVC framework that in my opinion has far eclipsed Struts. In addition, I would recommend looking at Spring Web-flow for higher level GUI flow design.
发布评论
评论（3）
Struts 是一个在 J2EE Web 应用程序中使用的框架，它试图为 Web 应用程序提供基于 MVC 模式的编码方法。 它包括一些用于表单数据验证等的附加实用程序。它是一个开源项目，非常擅长解决 Web 应用程序难题的特定部分，但仅限于解决该特定部分。
另一方面，ATG (ATG Dynamo) 是一个应用程序平台 - 一个解决方案和一个框架 - 用于构建数据和内容驱动的 Web 应用程序 - 主要用于商业和出版。 在框架层面，它是一个基于Java的应用程序平台，用于托管基于Web的应用程序以及RMI可访问的业务组件，具有ORM层、组件容器、MVC框架和一组JSP标记库。 组件框架（The Nucleus）是一个轻量级容器，用于管理 Java 组件对象（bean）的生命周期和依赖关系绑定（依赖注入）。 从这个意义上说，它有点类似于 Spring bean 容器，并且是 ATG 框架的核心 - 所有其他服务和框架都托管在其中。 ORM 层框架（存储库）将对象映射到关系数据库或从关系数据库映射对象（如您所期望的）。 但它还可以使用相同的一致数据访问 API 处理与 LDAP、XML 和文件系统数据源的映射。 用于将页面上的表单元素绑定到业务对象等上的值的 JSP 标记比我见过的任何其他框架中的表单绑定标记更优雅、更简洁。 编写您自己的标记库等效项 (Droplets) 的机制比标准 J2EE 标记更符合 Servlet API。
MVC 框架（基本的 Form 处理程序模式）有点类似于 Struts Form 和 Action 类 - 但提供了一个比 Struts 更基本的框架。 开箱即用，在大多数开发人员工作的级别上，ATG 模型是页面驱动的，而不是控制器驱动的。 在内部，它当然是控制器驱动的，并采用管道方法来链接调度程序和控制器。
此外，基础级别的框架为您提供了 RMI 容器、分布式缓存、分布式锁定和分布式单例、分布式事件和消息传递、任务调度程序、规则引擎以及用于定义具有自定义操作和结果的业务工作流的机制，用于业务工作流程的图形编辑器、对版本化数据的支持、对角色和权限的支持、日志记录和审核 - 全部开箱即用，并且全部使用非常连贯和一致的 API
然后在解决方案级别，您拥有用于处理问题的组件和 API包括用户分析、身份管理和个性化、内容创作、版本控制和发布、内容搜索、有形和无形商品的产品目录、产品搜索和引导导航、定价、税收计算、促销、购物车、礼品清单和愿望清单、付款 。
ATG 的扩展点和集成点通常设计得很好并且有很好的文档记录 它们支持与电子商务和出版领域的几乎任何人集成，例如创作和内容管理、身份管理和安全、产品目录、搜索和引导导航等。此外，框架的几乎所有领域都是可扩展的和可插拔的，这样您就可以编写自己的组件来增强或替换开箱即用的组件。
比较两者确实没有多大意义。 然而，考虑到你的问题，我想你真正感兴趣的是 ATG 的 MVC 部分
，对于 MVC，Struts 为你提供的比 ATG 提供的更多（但 Spring MVC 为你提供的甚至比 Struts 提供的更多）。 然而，使用 Struts 比使用 ATG 更容易陷入框架机制的困境。
就我个人而言，我认为 ATG 基于表单处理程序的模型比我见过的大多数其他 Web MVC 框架更优雅、更干净、更易于使用，并且 API 与 Servlet API 更一致。
还要记住，大多数“web-MVC”框架并不像真正的 MVC（即 Smalltalk 甚至 Java Swing 等中用于 GUI 编程的模式）。 Struts 和 ATG 都没有提供（按设计）真正的 MVC - 尽管 ATG 实际上更接近。 术语有很多混乱。
例如，
模型既不是您的数据模型，也不是您的域模型对象。 它是代表视图中所有数据的模型。 如果这恰好是一个域模型对象，那么很好 - 但通常情况下，您会发现您需要一组不同的视图或表单对象。 此外，模型还负责保持自身更新——它是与底层业务服务交互的模型。 ATG 倾向于将模型和控制器融合为一个组件 - 表单处理程序。 Struts 倾向于保持视图数据模型（表单对象）的独特性，但不鼓励将其用作真正 MVC 意义上的模型 - 它不是与其他业务服务交互以保持自身更新的表单对象。
MVC 中的C控制器不是您的业务控制器。 MVC 中的控制器是视图和模型之间的管道。 它对视图中的更改或对视图执行的操作做出反应，并指示模型相应地更新自身。 在 Struts 中，他们谈论的控制器根本不是 MVC 控制器——它实际上是一个调度程序。 控制器中的许多代码最终都在您的 Action 类中。 但按照 Struts 的设计方式，Action 类实际上是为了完成 Model 所做的事情。
MVC 中的 Vview 应该由模型填充 - 它是模型更新视图的推送机制，而不是视图查询模型的拉取机制。 在大多数 Web-MVC 框架中，视图（通常是 JSP）从模型中提取状态以显示自身。 ATG 的页面驱动方法尤其如此。 如果您发现在渲染页面时正在获取数据，则意味着您的 MVC 设计存在问题。
在Struts中，MVC Controller的功能分布在Struts控制器和Action上，而MVC Model的功能分布在Form对象和Action上。
在ATG中，MVC控制器和MVC模型的功能都在Form-handler中。
不过，由于HTTP的请求-响应性质，Web-MVC框架中控制器的功能相当有限。 对于 Web 应用程序，我们倾向于获得表单提交的完全更新的视图，而不是像使用丰富的 UI 框架那样进行大量的小更改（例如每次按键或鼠标单击，或每个更改的输入字段）。 AJAX 的使用正在改变这一点 - 我们必须更多地考虑如何正确实现 MVC。
请记住，MVC 是一种设计模式 - 即，它是设计应用程序的 GUI 方面时使用的设计时原则。 Struts 和 ATG 是框架 - 即它们是在构建应用程序时要扩展、实现或配置的类和对象。 框架不能强制使用设计模式——它只能鼓励它。 选择使用特定的框架并不会让你更好地设计你的ciode——最多它可能会鼓励某种纪律。
如果你的 MVC 设计得好，那么无论你使用 Struts 类还是 ATG 类来实现它，都不会产生太大的差异。 同样，如果你的 MVC 设计得很糟糕，希望你选择的框架能够弥补你的不足，那么无论你使用 Struts 还是 ATG 都不会产生太大的区别。 如果您理解并使用设计原则，您会发现在框架之间来回切换非常容易。
最好的代码将是在抽象中遵循良好的设计原则（例如，真正的 MVC），并使用所选框架中可用的正确工具按照其预期使用方式来实现（实现）它。
回到你的问题；
如果您正在从事 ATG 项目，则应该使用 ATG 提供的框架。 当然可以将 Struts 硬塞到 ATG 应用程序中 - 我自己很多年前就这样做过 - 但它的努力远远超出了它的价值 - 并且你放弃了 ATG 提供的很多开箱即用的功能对象生命周期管理、表单数据绑定等。
如果您即将开始一个新项目并可以选择使用的框架 - 我个人会推荐开源应用程序服务器（如 JBoss）和 Spring 框架 -它为您提供了 ATG 和 Struts 所提供的最佳功能。 它有一个类似 Nucleus 的组件容器（应用程序上下文），它与所有优秀的 ORM 解决方案（例如 Hibernate）集成，并包含一个在我看来远远超越 Struts 的 MVC 框架。 此外，我建议查看 Spring Web-flow 来进行更高级别的 GUI 流程设计。
Struts is a framework for using within a J2EE web application that tries to provide web applications with an MVC-pattern based approach to coding. It includes some added utilities for form data validation etc. It is an open source project, and has been quite good at solving that particular piece of the web application puzzle, and is limited to only solving that particular piece.
ATG (ATG Dynamo), on the other hand, is an application platform - a solution and a framework - for building data- and content- driven web applications - largely for commerce and publishing. At the framework level, it is a Java based application platform for hosting web-based applications, as well as RMI accessible business components, with an ORM layer, a component container, an MVC framework, and a set of tag libraries for JSP. The component framework (The Nucleus) is a lightweight container for managing the life cycle and dependency binding (dependency injection) of Java component objects (beans). In that sense it is somewhat similar to the Spring bean container, and is the core of the ATG framework - all other services and frameworks are hosted within it. The ORM layer framework (Repositories) maps objects to and from relational databases (as you would expect). But it can also handles mapping with LDAP, XML and file system data ources using the same consistent data access API. The JSP tags for binding form elements on a page to values on business objects etc. are more elegant and cleaner than the form binding tags in any other framework I have seen. The mechanism of writing your own tag library equivalents (Droplets) is much more consistent with the Servlet API than standard J2EE tags.
The MVC framework (the basic Form handler pattern) is somewhat similar to Struts Form and Action classes - but provides a much more basic framework that Struts does. Out of the box, and at the level at which most developers work, the ATG model is page-driven not controller-driven. Internally, it is certainly controller-driven with a pipeline approach to chaining dispatchers and controllers.
In addition, the framework at the basic level gives you an RMI container, distributed caching, distributed locking and distributed singletons, distributed events and messaging, a task scheduler, a rules engine and a mechanism for defining business workflows with custom actions and outcomes, a graphical editor for business workflows, support for versioned data, support for roles and rights, logging and auditing - all out of the box, and all using very coherent and consistent APIs
Then at the solution level, you have the components and the APIs for dealing with user profiling, identity management and personalization, content authoring, versioning and publishing, content search, product catalogs for tangible and intangible goods, product search and guided navigation, pricing, tax calculation, promotions, shopping carts, gift lists and wish lists, payment types, shipping methods, order tracking, customer relationship management etc.
The extension points and integration points to ATG are usually very well designed and quite well documented. They support integration with pretty much anyone who is anyone in the e-commerce and publishing space for things like authoring and content management, identity management and security, product catalogs, search and guided navigation etc. Also, almost all areas of the framework are extensible and plug-gable so you can write your own components to enhance or replace the ones out of the box.
It does not really make much sense to compare the two. However, given your question, I imagine what you are really interested in is the MVC part of ATG
For MVC, Struts gives you more than ATG does (but then Spring MVC gives you even more than Struts does). However, you tend to get bogged down in the mechanics of the framework far more with Struts than with ATG.
Personally, I think that ATG's form-handler based model is more elegant, cleaner and easier to work with than most other web MVC frameworks I have seen, and the APIs are more consistent with the Servlet APIs.
Bear in mind, also, that most 'web-MVC' frameworks are not like true MVC (i.e. the pattern used for GUI programming in Smalltalk or even Java Swing etc.). Neither Struts nor ATG provide (as designed) true MVC - though ATG actually comes closer. There is a lot of confusion about terminology.
For example,
the Model in true MVC is not your data model nor your domain model objects. It is the model that represents all the data in a view. If that happens to be a domain model object then well and good - but more often than not, you will find that you need a different set of view or form objects. Also, the model is responsible for keeping itself updated - it is the Model that interacts with business services lower down. ATG tends to fuse the model and the controller into one component - the form-handler. Struts tends to keep the view data model distinct (the form object), but does not encourage its use as a model in the true MVC sense - it is not the form object that interacts with other business services to keep itself updated.
the Controller in MVC is not your business controller. A controller in MVC is a conduit between the view and the model. It reacts to changes in the view, or to actions performed on the view, and instructs the model to update itself accordingly. In Struts the Controller they talk about is not an MVC controller at all - it is really a dispatcher. A lot of the code that belongs in a controller ends up in your Action class. But the way Struts is designed, the Action class is really meant to do what a Model does.
the View in MVC should be populated by the model - it is a push mechanism with the model updating the view, not a pull mechanism with the view querying the model. In most web-MVC frameworks, the view (usually a JSP) pulls state from the model in order to display itself. This is particularly the case with ATG's page-driven approach. If you find that data is being fetched while your page is rendering it means something is wrong with your MVC design.
In Struts, the function of the MVC Controller is spread across the Struts controller and the Action, while the function of the MVC Model is spread across the Form object and the Action.
In ATG, the function of the MVC Controller and the MVC Model is all in the Form-handler
Having said that, due to the request-response nature of HTTP, the function of a Controller in a web-MVC framework is quite limited. With web applications, we tend to get a completely updated view on form submission rather than lots of small changes (e.g. each key press or mouse click, or each changed input field) as we would with a rich UI framework. The use of AJAX is changing that - and we have to think much more about implementing MVC correctly.
Remember, MVC is a design pattern - i.e. it is a design-time principle to be used when designing the GUI aspect of applications. Struts, and ATG are frameworks - i.e. they are classes and objects to be extended, implemented or configured when building your application. A framework cannot enforce the use of a design pattern - it can merely encourage it. Choosing to use a particular framework will not make you design your ciode better - at most it may encourage a certain discipline.
If you design your MVC well, it will not make a huge difference whether you use Struts classes or ATG classes to implement it. Likewise, if you design your MVC badly, hoping that your choice of framework will make up for your shortfalls, it will not make a huge difference whether you use Struts or ATG. If you understand and work with the design principles, you will find it very easy to switch back and forth between frameworks.
The best code will be that which adheres to a good design principle (say, true MVC) in the abstract, and implements it (realizes it) using the right tools available in the chosen framework in the way they are intended to be used.
Coming back to your question;
If you are working on an ATG project, you should use the frameworks that ATG provides. It is certainly possible to shoehorn Struts into an ATG application - I have done this myself many years ago - but it is far more effort than it is worth - and you are giving up a lot of what ATG provides out of the box in terms of object life-cycle management, form data binding etc..
If you are about to start work on a new project and have a choice of frameworks to use - I would personally recommend an open source application server (like JBoss) and the Spring Framework - it gives you the best of what ATG and Struts provide. It has a Nucleus-like component container (the Application Context), it integrates with all good ORM solutions (such as Hibernate) and includes an MVC framework that in my opinion has far eclipsed Struts. In addition, I would recommend looking at Spring Web-flow for higher level GUI flow design.
在英国的主要区别在于，作为 ATG 承包商，您每天可以获得 500 英镑，但作为一般 Struts 人员，您很幸运能够获得 350 英镑。
并不是说我很苦涩。
The main difference in the UK is that as an ATG contractor you can get £500 per day, but as a general Struts guy you're lucky to get £350.
Not that I'm bitter at all.
ATG 是专有软件...并且资源较少...
ATG is proprietary software... and resources are less ...