blocks|key|366568|text|..but+Javascript有许多是面向对象的方面。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|366569|请考虑以下内容：|366570|var+Vehicle+=+jQuery.Class.create({+
+++init:+function(name)+{+this.name+=+name;+}+
});

var+Car+=+Vehicle.extend({+
+++fillGas:+function(){+
++++++this.gas+=+100;+
+++}+
});|code-block|syntax|javascript|366571|我使用这种技术来创建具有自己状态的页面级javascript类，这有助于保持它的可控性(我经常确定可以重用的区域并将其放入其他类中)。|366572|当您有自己的脚本要执行的组件/服务器控件时，但在同一页上可能有多个实例时，这也特别有用。这保持了状态的分离。|366573|entityMap^0|J|1|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|W|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|X|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|Y|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|R|$]]

..but Javascript has many facets that are OO.

Consider this:

<pre><code>var Vehicle = jQuery.Class.create({ 
 init: function(name) { this.name = name; } 
});

var Car = Vehicle.extend({ 
 fillGas: function(){ 
 this.gas = 100; 
 } 
});
</code></pre>

I've used this technique to create page-level javascript classes that have their own state, this helps keep it contained (and I often identify areas that I can reuse and put into other classes).

This is also especially useful when you have components/server controls that have their own script to execute, but when you might have multiple instances on the same page. This keeps the state separate.

blocks|key|369638|text|不是100%25确定你在这里的意思，但我会说，在做了过去6年的ASP.NET之后，一旦服务器完成了基本的页面渲染，我的网页现在主要是由JavaScript驱动的。我将JSON用于任何事情(已经使用了大约3年)，并使用来满足我的客户端需求。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|369639|顺便说一句，JavaScript是面向对象的，但由于它使用了原型继承，人们不会以这种方式给予它信任。我还认为它也是功能性的，这完全取决于你如何编写它。如果您真的对函数式编程风格感兴趣，请查看+-您可能会喜欢它；它在很大程度上倾向于JavaScript的函数式编程。|369640|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Not 100% sure what you mean here, but I will say that after doing ASP.NET for the last 6 years, my web pages are now mostly driven by JavaScript once the basic page rendering is done by the server. I use JSON for everything (have been for about 3 years now) and use <a href="http://www.mochikit.com" rel="nofollow noreferrer">MochiKit</a> for my client-side needs.

By the way, JavaScript is OO, but since it uses prototypical inheritance, people don't give it credit in that way. I would also argue that it is functional as well, it all depends on how you write it. If you are really interested in functional programming styles, check out <a href="http://www.mochikit.com" rel="nofollow noreferrer">MochiKit</a> - you may like it; it leans quite a bit towards the functional programming side of JavaScript.

blocks|key|369645|text|MochiKit非常棒--可以说，就js库而言，它是我的最爱。但我发现，虽然MochiKit有非常丰富的语法，但我对它的感觉远不如Prototype/MochiKit或jQuery让我觉得舒服。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|369646|我认为如果你知道或者喜欢python，那么MochiKit对你来说是一个很好的工具。|369647|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

MochiKit is great -- and was my first love, so-to-speak, as far as js libraries go. But I found that while MochiKit has very expressive syntax, it didn't feel nearly as comfortable to me as Prototype/Scriptaculous or jQuery did for me.

I think if you know or like python, then MochiKit is a good tool for you.

blocks|key|3161600|text|特里斯坦，你会发现，当你试图将JavaScript构建成一个MVC应用程序时，它往往在一个方面做不到--模型。最难处理的领域是模型，因为数据不会在整个应用程序中持续存在，而且从本质上讲，模型在客户端的变化似乎相当一致。您可以标准化从服务器传递和接收数据的方式，但是此时模型并不真正属于JavaScript+--它属于您的服务器端应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3161601|我曾经看到过一次尝试，有人创建了一个用JavaScript建模数据的框架，就像SQLite属于应用程序的方式一样。它就像Model.select(“产品”)和Model.update(“产品”，“一些数据...”)。它基本上是一个对象表示法，它保存了一堆数据来管理当前页面的状态。但是，当您刷新时，所有数据都会丢失。我可能对语法不太了解，但是你明白我的意思。|3161602|如果你正在使用jQuery，那么Ben的方法真的是最好的。使用您的函数和属性扩展jQuery对象，然后划分您的“控制器”。我通常将它们放入单独的源文件中，并逐节加载它们。例如，如果它是一个电子商务站点，我可能有一个充满控制器的JS文件，这些控制器处理结帐过程的功能。这往往会让事情变得轻量级且易于管理。|3161603|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Tristan, you will find that when you try to architecture JavaScript as an MVC application it tends to come up short in one area -- the model. The most difficult area to deal with is the model because the data does not persist throughout the application, and by nature the models seem to change on the client-side pretty consistently. You could standardize how you pass and receive data from the server, but then at that point the model does not really belong to JavaScript -- it belongs to your server-side application.

I did see one attempt awhile back where someone created a framework for modeling data in JavaScript, much like the way SQLite belongs to the application. It was like Model.select( "Product" ) and Model.update( "Product", "Some data..." ). It was basically an object notation that held a bunch of data to manage the state of the current page. However, the minute you refresh, all that data is lost. I'm probably off on the syntax, but you get the point.

If you are using jQuery, then Ben's approach is really the best. Extend the jQuery object with your functions and properties, and then compartmentalize your "controllers". I usually do this by putting them into separate source files, and loading them on a section-by-section basis. For instance, if it were an e-commerce site, I might have a JS file full of controllers that handle functionality for the checkout process. This tends to keep things lightweight and easy to manage.

blocks|key|364854|text|只是快速澄清一下。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364855|编写不面向服务器的GWT应用程序是完全可行的。我假设从面向服务器的角度来说，您指的是需要基于java的后端的GWT+RPC。|364856|我已经编写了GWT应用程序，这些应用程序仅在客户端就非常"MVC-ish“。|364857|364858|模型是一个对象图。尽管您使用Java编写代码，但在运行时，对象是javascript格式的，客户端或服务器端都不需要任何JVM。GWT还通过完整的解析和操作支持来支持JSON。您可以轻松地连接到JSON+webservices，有关JSON+mashup示例，请参阅2。观察者视图是由标准的GWT+(加上我们自己的一些复合widgets)|unordered-list-item|offset|length|364859|Controller层通过观察者模式与|364860|分离而成)组成的。|364861|364862|如果您的“强类型”背景是Java或类似的语言，我认为您应该认真考虑在大型项目中使用GWT。对于小项目，我通常更喜欢jQuery。即将到来的与GWT1.5协同工作的GWTQuery可能会改变这一点，尽管不会在不久的将来，因为有大量的jQuery插件。|364863|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/support/bin/answer.py?answer=65632&topic=11368|1|http://code.google.com/p/gwtquery/^0|0|0|0|0|3P|1|0|0|0|0|0|29|8|1|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|16|8|@]|9|@$J|17|K|18|1|19]]|A|$]]|$1|L|3|M|5|I|7|1A|8|@]|9|@]|A|$]]|$1|N|3|O|5|I|7|1B|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1D|8|@]|9|@$J|1E|K|1F|1|1G]]|A|$]]|$1|S|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]|10|$5|V|W|X|A|$Y|11]]]]

Just a quick clarification. 

It is perfectly feasible to write GWT apps that are not server-oriented. I am assuming that from Server-Oriented you mean GWT RPC that needs java based back-end. 

I have written GWT apps that are very "MVC-ish" on the client side alone. 

<ul>
<li>The model was an object graph. Although you code in Java, at runtime the objects are in javascript with no need of any JVM in either client or server-side. GWT also supports JSON with complete parsing and manipulation support. You can connect to JSON webservices easily, see <a href="http://code.google.com/support/bin/answer.py?answer=65632&amp;topic=11368" rel="nofollow noreferrer">2</a> for a JSON mashup example. </li>
<li>View was composed of standard GWT widgets (plus some of our own composite widgets)</li>
<li>Controller layer was neatly separated from View via Observer pattern.</li>
</ul>

If your "strongly-typed" background is with Java or similar language, I think you should seriously consider GWT for large projects. For small projects I usually prefer jQuery. Upcoming <a href="http://code.google.com/p/gwtquery/" rel="nofollow noreferrer">GWTQuery</a> that works with GWT 1.5 may change that though not in near future because of abundance of plugins for jQuery.

blocks|key|3161650|text|对于组织和开发大型JS应用程序，JavaScriptMVC是一个很好的选择。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3161651|架构设计考虑得很周到。你可以用JavaScript做4件事：|3161652|3161653|+response+to+a+event+|ordered-list-item|3161654|Request+Data+/+Manipulate+(+ajax+)+|3161655|将特定于域的信息添加到ajax响应中。|3161656|更新DOM|3161657|3161658|JMVC将它们划分为模型、视图、控制器模式。|3161659|首先，也可能是最重要的优势，是控制器。控制器使用事件委托，因此您只需为页面创建规则，而不是附加事件。它们还使用控制器的名称来限制控制器工作的范围。这使得你的代码是确定性的，这意味着如果你在一个'#+todos‘元素中看到一个事件发生，你就知道必须有一个todos控制器。|3161660|$.Controller.extend('TodosController',{
+++'click'+:+function(el,+ev){+...+},
+++'.delete+mouseover':+function(el,+ev){+...}
+++'.drag+draginit'+:+function(el,+ev,+drag){+...}
})|code-block|syntax|javascript|3161661|接下来是模型。JMVC提供了一个强大的类和基本模型，使您可以快速组织Ajax功能(#2)，并使用特定于域的功能包装数据(#3)。完成后，您可以使用控制器中的模型，如下所示：|3161662|Todo.findAll({after:+new+Date()}，myCallbackFunction)；|3161663|最后，一旦你的待办事项回来了，你必须展示它们(#4)。这就是您使用JMVC视图的地方。|3161664|'.show+click'+:+function(el,+ev){+
+++Todo.findAll({after:+new+Date()},+this.callback('list'));
},
list+:+function(todos){
+++$('#todos').html(+this.view(todos));
}|3161665|在'views/todos/list.ejs‘中|3161666|<%25+for(var+i+=0;+i+<+this.length;+i%2B%2B){+%25>
+++<label><%25=+this[i].description+%25></label>
<%25}%25>|3161667|JMVC提供的不仅仅是架构。在开发周期的任何部分，它都可以帮助您：|3161668|3161669|Code+generators|unordered-list-item|3161670|Integrated+Browser、Selenium和Rhino+Testing|3161671|Documentation|3161672|Script+compression|3161673|Error+reporting|3161674|3161675|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1R|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|1T|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|1U|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|1V|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|1W|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|S|3|T|5|U|7|20|8|@]|9|@]|A|$V|W]]|$1|X|3|Y|5|6|7|21|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|22|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|23|8|@]|9|@]|A|$]]|$1|13|3|14|5|U|7|24|8|@]|9|@]|A|$V|W]]|$1|15|3|16|5|6|7|25|8|@]|9|@]|A|$]]|$1|17|3|18|5|U|7|26|8|@]|9|@]|A|$V|W]]|$1|19|3|1A|5|6|7|27|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|28|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|1E|7|29|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|1E|7|2A|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|1E|7|2B|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|1E|7|2C|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|1E|7|2D|8|@]|9|@]|A|$]]|$1|1N|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1O|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]]|1P|$]]

JavaScriptMVC is a great choice for organizing and developing a large scale JS application.

The architecture design very well thought out. There are 4 things you will ever do with JavaScript:

<ol>
<li>Respond to an event </li>
<li>Request Data / Manipulate Services (Ajax) </li>
<li>Add domain specific information to the ajax response. </li>
<li>Update the DOM</li>
</ol>

JMVC splits these into the Model, View, Controller pattern.

First, and probably the most important advantage, is the Controller. Controllers use event delegation, so instead of attaching events, you simply create rules for your page. They also use the name of the Controller to limit the scope of what the controller works on. This makes your code deterministic, meaning if you see an event happen in a '#todos' element you know there has to be a todos controller.

<pre><code>$.Controller.extend('TodosController',{
 'click' : function(el, ev){ ... },
 '.delete mouseover': function(el, ev){ ...}
 '.drag draginit' : function(el, ev, drag){ ...}
})
</code></pre>

Next comes the model. JMVC provides a powerful Class and basic model that lets you quickly organize Ajax functionality (#2) and wrap the data with domain specific functionality (#3). When complete, you can use models from your controller like:

Todo.findAll({after: new Date()}, myCallbackFunction);

Finally, once your todos come back, you have to display them (#4). This is where you use JMVC's view. 

<pre><code>'.show click' : function(el, ev){ 
 Todo.findAll({after: new Date()}, this.callback('list'));
},
list : function(todos){
 $('#todos').html( this.view(todos));
}
</code></pre>

In 'views/todos/list.ejs'

<pre><code>&lt;% for(var i =0; i &lt; this.length; i++){ %&gt;
 &lt;label&gt;&lt;%= this[i].description %&gt;&lt;/label&gt;
&lt;%}%&gt;
</code></pre>

JMVC provides a lot more than architecture. It helps you in ever part of the development cycle with:

<ul>
<li>Code generators</li>
<li>Integrated Browser, Selenium, and Rhino Testing</li>
<li>Documentation</li>
<li>Script compression</li>
<li>Error reporting</li>
</ul>

How is your javaScript code organized? Does it follow patterns like MVC, or something else? 

I've been working on a side project for some time now, and the further I get, the more my webpage has turned into a full-featured application. Right now, I'm sticking with <a href="http://jquery.com" rel="noreferrer">jQuery</a>, however, the logic on the page is growing to a point where some organization, or dare I say it, "architecture" is needed. My first approach is "MVC-ish":

<ul>
<li>The 'model' is a JSON tree that gets extended with helpers</li>
<li>The view is the DOM plus classes that tweak it</li>
<li>The controller is the object where I connect events handling and kick off view or model manipulation</li>
</ul>

I'm very interested, however, in how other people have built more substantial javaScript apps. I'm not interested in GWT, or other server-oriented approaches... just in the approach of "javaScript + &lt;generic web service-y thingy here&gt;"

Note: earlier I said javaScript "is not really OO, not really functional". This, I think, distracted everyone. Let's put it this way, because javaScript is unique in many ways, and I'm coming from a strongly-typed background, I don't want to force paradigms I know but were developed in very different languages.

Alternative "architectural" approaches to javaScript client code?

服务器

jQuery

SQLite

JSON

Java

您的javaScript代码是如何组织的？它是否遵循像MVC这样的模式，或者其他什么？我从事一个副业已经有一段时间了，我做得越深入，我的网页就越能变成一个功能齐全的应用程序。现在，我坚持使用，然而，页面上的逻辑正在增长到需要某种组织，或者说我敢说，“架构”的程度。我的第一种方法是"MVC-ish"：‘’是一个JSON树...

问javaScript客户端代码的替代“架构”方法？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问javaScript客户端代码的替代“架构”方法？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问javaScript客户端代码的替代“架构”方法？
EN