2012-09-12 19 views
5

Tengo un código de Javascript de procedimiento que he escrito para una aplicación de código abierto y me gustaría refactorizarlo en OOP y dado que tengo muy poca experiencia con frameworks de JavaScript, tengo problemas para encontrar un una adecuada para mis necesidades, aunque todavía no he probado nada, acabo de leer sobre AngularJS, Backbone.js y Knockout.Marco para estructurar código JS existente

Quiero estructurar el código, porque, por el momento, hay un caos, variables globales y funciones dispersas.

Debo mencionar que toda la lógica de negocios se maneja en el nivel del servidor, por lo que el código del lado del cliente maneja solo la UI utilizando los datos que recibe o las solicitudes del servidor.

El código se puede encontrar aquí: https://github.com/paullik/webchat/blob/asp.net/webchat/Static/Js/chat.js

¿Tiene alguna sugerencia?

+0

En primer lugar, recomiendo encarecidamente que capte los fundamentos de javascript antes de decidir utilizar un marco; no es difícil hacer javascript orientado a objetos ([esto es algo que debe leerse] (http://shop.oreilly.com/product/9780596517748.do)). Existen numerosos marcos (nodo, columna vertebral, red troncal, etc.) que proporcionan sus propias formas de definir y extender objetos, pero no conozco lo suficiente como para ofrecer una comparación decente. – RobMasters

+0

@RobMasters JS no es mi problema, tal vez no conozco todos los trucos de JS, pero puedo escribir JS sin problemas. De todos modos, gracias por la sugerencia, seguramente marcaré el enlace al que hiciste referencia. – Paul

Respuesta

5

JavaScript orientado a objetos no es necesariamente la respuesta a todos sus problemas de .

Mi consejo es que tenga cuidado con la elección que elija sobre este tema.

En la práctica, OO-JS puede agregar más complejidad a su código por el simple hecho de intentar ser más parecido a los lenguajes orientados a objetos tradicionales. Como probablemente sepa, JS es único.

Es importante saber que hay patrones de diseño que estructurarán su código y mantendrán la implementación ligera y flexible.

Es patrones de diseño que veo la estructuración de implementaciones avanzadas JS , no OO. Parafraseando a Axel Rauchmeyer - "Objeto La metodología orientada no encaja en la sintaxis básica de JavaScript, es una implementación retorcida y contorsionada, y JS es mucho más expresiva sin ella".

La raíz de este análisis se reduce al hecho de que JS no tiene ninguna clase. En esencia, dado que todo es un objeto, ya tiene variables y funciones orientadas a objetos. Por lo tanto, el problema es ligeramente diferente al que se encuentra en los lenguajes compilados (C/Java).

¿Qué patrones de diseño hay para JavaScript?

Un excelente recurso para comprobar es Addy O 'Somani y Essential Design Patterns. He wrote this book on Design Patterns in JavaScript.

Pero hay más ... mucho más.

A. require.js - Hay una manera de cargar módulos de código JS de una manera muy impresionante. Estos generalmente se denominan cargadores de módulos y se consideran ampliamente como el futuro de la carga de archivos js, ya que optimizan el rendimiento en tiempo de ejecución. yepnope y otros existen. Tenga esto en cuenta si está cargando más de unos pocos archivos js. (movido a la parte superior por solicitud).

B. MVC: hay docenas de marcos de Model View Controller para ayudarlo a estructurar el código. Es un patrón, pero puede ser irrazonable para sus propósitos.Mencionaste columna vertebral, knockout y angular ... Sí. Estos pueden ser el truco para usted, pero me preocuparía que puedan ser 1) alta curva de aprendizaje, y 2) excesiva para su entorno.

C. Espacio de nombres o patrón de módulo. Son probablemente las más importantes para sus necesidades. Para resolver las variables globales simplemente envuélvalas en un espacio de nombres y haga referencia a eso. Estos son muy buenos patrones que dan lugar a los cargadores de módulos.

D. Cierre: ha mencionado OO JS. Una parte de esto que es útil es la noción de cierres para proporcionarse ... con miembros privados. Al principio, esta es una idea críptica, pero después de reconocer el patrón, es una práctica trivial.

E. Eventos personalizados: se vuelve muy importante no utilizar referencias duras entre objetos. Ejemplo: AnotherObject.member; Esto se debe a que unirá estrechamente los dos objetos y hará que ambos sean inflexibles para cambiar. Para resolver esto, activa y escucha eventos. En los patrones de diseño tradicionales, este es el observador. En JS se llama PubSub.

F. La devolución de llamada: el patrón de devolución de llamada es lo que habilitó AJAX y está revolucionando el desarrollo en términos de Window 8, Firefox OS y Node.js, debido a algo llamado no-blocking-io. Muy importante.

No tengas miedo. Esta es la dirección a seguir para implementaciones JavaScript a largo plazo y avanzadas.

Una vez que reconoces los patrones, desde ese punto está en declive.

Espero que esto ayude.

+1

Pondría el RequireJS en la parte superior. Proporciona modularidad, maneja dependencias de módulos y permite la construcción/minificación automatizada de una manera inteligente. Independientemente de lo que se use debajo, require.js trae mucha cordura a una base de código más grande. También hay alternativas, pero el enfoque general de AMD (definición de módulo asíncrono) es una necesidad para conquistar. De todos modos, podría reformular su respuesta, y alguien podría reformular la mía, pero el enfoque general y la lista de cosas para saber serán esencialmente iguales. –

+0

De hecho, buena sugerencia, cambio realizado. +1 –

+1

Gracias, así que decidí no usar un framework (que no sea require.js tal vez), sino que refactorizar mi código usando algunos de los conceptos que mencioné allí (algunos de los cuales ya estoy familiarizado y usarlos en codificar con frecuencia). Además, una estructura multiescala de espacio de nombres puede poner orden en mi código JS. – Paul

Cuestiones relacionadas