我应该使用什么架构模式进行RIA？ [英] What architectural pattern(s) should I use for my RIA?

问题描述

应用程序概述：交互时，我可以使用这个应用程序具有引导用户编辑页面的工具栏和叠加层，然后将已编辑的页面发送回服务器。

到目前为止，我已经成功构建了我想要的它是JQuery所有捆绑在一起，我需要帮助如何重写我的代码，使其可扩展和可维护。

研究至今：

• RequireJS - 我已经看过RequireJS，并认为这是一个很好的起点，并且一切正常。


• JQuery -


• Nicholas Zakas关于可扩展JavaScript应用程序架构的演讲 - 令人敬畏的想法，但是如何实现？我对高级JavaScript非常新颖。

我还需要一些事件池来管理所有这些事件。如果我使用JQuery的内置事件池绑定，触发器，这不会迫使我远离Zakas的想法，只有我的应用程序核心才能访问我的JQuery库？

我应该查看什么类型的框架来解决我的问题？

解决方案

你实际上是要求更多不止一个问题。我正在分析我们公司的我应该使用什么框架的问题。这需要比你想象的更多。以下是我到目前为止，当我得到更多的细节，我会尝试更新这个项目。

同时...

建筑模式的问题与图书馆或框架的问题不同。

建筑设计模式 由于很多原因是有用的。一个原因是在模块中实现松耦合。在

使用哪个框架的问题有许多决定点： br />

• JavaScript Famework Usage


• Google趋势


• JavaScript框架的比较

速度测试

• 光滑速度


• 任务速度


• 编写自己的测试，像这个人做的

这些是我考虑的框架框架：

• Dojo


• jQuery ：仅当包含伞模块时才是框架（可以用作孤立库）


• YUI


• Mootools


• <啊ref =http://prototypejs.org/ =nofollow noreferrer> 原型

我决定将我的框架选择限制为：

1. Dojo ：工具包，桌面，美孚，图形和;矢量化


2. YUI ：开发人员工具，基础架构，实用程序，小部件，图库，项目


3. jQuery < a> ：核心，UI，Mobil，插件，图形，可视化

JavaScript LIBRARIES也是需要的：

MVC是最常用的前端模式。但是，我的笔记还没有完成。即使我无法找到上面列出的项目的使用统计资料。

Backbone.js （MVC）

设计更多地用于消费REST数据。 Backbone有自己的事件系统，因此与jQuery功能竞争。

Spine.js （MVC）

JavaScriptMVC （MVC）

MVC集成开发工具;与jQuery一起使用高度模块化还不确定它是否可以简单地被认为是一个图书馆，而不是...但是爸爸likey！

AngularJS （MVC）

分离问题，松耦合和反转控制。双向数据绑定

SproutCore （MVC）

YUILibrary （MVC）

这真的是整个YUI框架的一部分...但是被列在原来的源文章。

Broke.js （MVC）

文档目前很差。 p>

Fidel.js （MVC）

Sammy.js （MVC）

设计更多地用于消费REST数据。

KnockoutJS （MVVM）

问题：

• 为什么几个完全的MVVM实现？


• 双向绑定相同的东西作为MVVM？


• 如果是这样，为什么这些库（做双向绑定）认为自己是MVC？

模块化JAVASCRIPT： AMD ， CommonJS 和基于承诺的实施：

我仍​​然概述这一领域。但是，以下是我正在使用的一些领域的灵感。

• 我以前的一个问题


• 文章：使用AMD，CommonJS& ES Harmony


• 文章：我对AMD的想法


• 文章：创建大规模JavaScript应用程序


• 演讲：John Hann的AMD Patters


• 基本的jQuery插件模式由Addy Osmoni

问题：

• AMD有不同的味道（各种文章似乎都说是）？


• promises是什么意思？ / li>
  

创建窗口TS& PLUGINS：

一旦您决定了您的模块应该使用哪种风格的AMD，您实际上可以开始写入某些东西。

• 文章：编码您的第一个jQuery UI插件


• 文章：jQuery UI小部件工厂

问题：

• 插件和小部件有什么区别？

一般注意事项：
我建议您看看每个框架如何实现各种模块。看看完成某些事情所需的代码。感觉好吗？是否感到笨拙？

我的初始感觉：

查看趋势，用法，速度和广ness度社区支持选项... jQuery是领先的。

目标：

最终目标是选择一个框架，任何/所有库，并定义一个加载和创建松散耦合的JavaScript模块的一般方法。

按风险量化成本： br />
定价成本是很困难的，但你可以解释风险。在最终的判断中，您还应该考虑上面列出的趋势。但是，一般来说，我会将费用分散到3个定义风险的领域：

• 熟悉度：您现在最熟悉的是什么？


• 加速：在每个框架和库中都需要花费多少费用？


• 许可：这里是否有障碍？

风险：一旦评估，您可以正确解释为什么您可以将一个选项排列为低，中或高。

@ErezCohen

我们是一个ASP.NET商店，所以我们在我们的RESTFUL后端使用Web API。而且由于组件式JavaScript开发是未来，我们选择使用jQuery& RequireJS作为所有页面的标准基准。另外，我们在控制器中大量使用Deferreds。

对于客户端MVC，提到的框架太多比其他任何东西都更流行（和许多人已经在使用中衰退）。此外，当需求决定而不是标准时，将MVC / MVVM功能视为一次性附加组件更有意义。而且坦白说，由于我们发现Ajax的调用变得容易，因此大量的框架来做简单的数据绑定似乎很愚蠢（唯一真正的好处是对某些复杂的情况是双向约束的）。此外，考虑一旦这些框架不再受欢迎，就会有一些痛苦。

当然，我们有能力在我们的自己...你可能不会如果您的机组人员对JavaScript不是很好，请尝试Angular，因为它是针对设计师而不是程序员开发的。或者，如果您的团队能够自己滚动并且想要一个控制器框架，那么jQuery Widget Factory是有用的。然而，简单地使用模块模式为您的控制器也很好（就是我们这样做）。而且...它的工作非常好，而且非常干净。

I'm building a web application that interacts heavily with the DOM and need direction in making my code scalable and maintainable.

The application overview: Upon interaction, I have toolbars and overlays that guide the user to edit the page, I then send back the edited page to the server.

So far I've successfully built what I wanted but it's JQuery all tied together and I need help on how to rewrite my code to make it scalable and maintainable.

Research so far:

• RequireJS - I've looked at RequireJS and thought this was a great starting point and got it all working.
• JQuery - Can't get away from this awesome library.
• Nicholas Zakas' presentation on Scalable JavaScript Application Architecture - Awesome idea, but how do I implement this? I'm fairly new to advanced JavaScript.

I will also need some kind of event pooling to manage all these events. If I use JQuery's built-in event pooling "bind", "trigger", will this not force me away from Zakas' idea that only my application core should have access to my JQuery library?

What type of framework should I be looking at to solve my problem?

解决方案

You're actually asking more than one question. I am currently analyzing the "what framework should I use" question for our company. This entails a lot more than you think. Below is what I have so far, and as I get more details I will try to update this item.

In the meantime...

The question of architectural patterns is different from that of libraries or frameworks.

ARCHITECTURAL DESIGN PATTERNS are useful for many reasons. One reason would be to achieve loose coupling in your modules. A great example of how to achieve loose coupling is found in the Mediator Pattern.

The question of which framework to use has many decision points:

• JavaScript Famework Usage
• Google Trends
• Comparison of JavaScript frameworks

Speed Tests:

• Slick Speed
• Task Speed
• Write your own test like this guy did

These Are What I Consider FRAMEWORKS:

• Dojo
• jQuery: Is a framework only when 'umbrella' modules are included (can be used as a lone library)
• YUI
• Mootools
• Prototype

I have decided to limit my FRAMEWORK CHOICES to:

1. Dojo: Toolkit, Desktop, Mobil, Graphics & Vectoring
2. YUI: Developer Tools, Infrastructure, Utilities, Widgets, gallery, Projects
3. jQuery: Core, UI, Mobil, Plugins, Graphing, Visualization

But...a breakdown of JavaScript LIBRARIES is also needed:
MVC is the most commonly used front-end pattern. However, my notes here are not yet complete. Even I am having trouble finding usage statistics on the items listed above.

Backbone.js (MVC)
Designed more toward consuming REST data. Backbone has its own event system, and thus, competes with jQuery functionality.

Spine.js (MVC)

JavaScriptMVC (MVC)
MVC integrated development tools; is used with jQuery; Highly modularized. Not yet sure if it can simply be considered a library or not...but daddy likey!

AngularJS (MVC)
Separation of concerns, loose coupling, and inversion of control. Two-way databinding

SproutCore (MVC)

YUILibrary (MVC)
This is really part of the overall YUI framework…but was listed in the original source article.

Broke.js (MVC)
Documentation is currently poor.

Fidel.js (MVC)

Sammy.js (MVC)
Designed more toward consuming REST data.

KnockoutJS (MVVM)

QUESTIONS:

• Why are there so few outright MVVM implementations?
• Is Two-Way Binding the same thing as MVVM?
• If so, why do some of these libraries (that do two-way binding) consider themselves MVC?

MODULAR JAVASCRIPT: AMD, CommonJS and Promises-Based Implementations:
I am still outlining this area. However, below are some areas I am using for inspiration.

• A previous question of mine
• ARTICLE: Writing Modular JavaScript With AMD, CommonJS & ES Harmony
• ARTICLE: My Thoughts on AMD
• ARTICLE: Creating large-scale JavaScript Applications
• PRESENTATION: AMD Patters by John Hann
• Essential jQuery Plugin Patterns by Addy Osmoni

QUESTIONS:

• Are there different 'flavors' of AMD (various articles seem to say yes)?
• What does 'promises-based' mean?

CREATING WIDGETS & PLUGINS:
Once you decide on which flavor of AMD your modules should use you can actually begin writting something.

• ARTICLE: Coding your First jQuery UI Plugin
• ARTICLE: The jQuery UI Widget Factory

QUESTIONS:

• What is the difference between a plugin and a widget?

GENERAL NOTES:
I would suggest looking at how each of your frameworks implement various modules. Look at the code it takes to accomplish something. Does it feel right? Does it feel clunky?

MY INITIAL FEELING:
Looking at the trends, usage, speed and vastness of community support options...jQuery is way ahead.

THE GOAL:
The final goal is to choose a framework, any/all libraries and define a general approach for loading and creating loosely-coupled JavaScript Modules.

Quantifying Cost by Risk:
Quantiying cost outright is difficult, but you can explain-away risk. In your final desicion, you should also take into account the trends listed above. But, in general, I would loosely break-up cost into 3 areas that define RISK:

• Familiarity: What is your team most familiar with now?
• Ramping Up: How much extra-effort would it take to get "ramped-up" on each framework and library?
• Licensing: Are there any snags here?

Risk: Once assessed, you can rightfully explain WHY you might rank one option as low, medium or high.

@ErezCohen

We are an ASP.NET shop, so we use Web API for our RESTFUL backend. And since component-style JavaScript development is the future, we chose to use jQuery & RequireJS as a standard baseline on all our pages. Additionally, we make heavy use of Deferreds in our controllers.

As for client-side MVC, too many of the "frameworks" mentioned are more fads than anything else (and many have waned in use). Additionally, it made more sense to treat MVC/MVVM capabilities as a one-off add-on when requirements dictated rather than a standard. And, frankly, since we find making Ajax calls easy, brining-in vast frameworks to do simple data-binding seemed silly (the only real benefit is two-way binding for certain complex cases). Besides, think about what a pain it would be to decouple some of these frameworks once they are no longer popular.

Of course, we have the talent to do so on our own…you may not. If your crew isn’t very good with JavaScript, try Angular because it was developed for "designers" not programmers. Alternatively, if your team is capable of rolling-their-own and wants a framework for controllers then jQuery Widget Factory is useful. However, simple use of the Module Pattern for your controllers is fine too (that is what we do). And...it works great...and is VERY clean.

这篇关于我应该使用什么架构模式进行RIA？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！