2009-09-15 19 views
15

¿Hay alguna inversión de marcos de control para javascript?¿Hay alguna inversión de marcos de control para javascript?

La respuesta más cercana disponible en stackoverflow que pude encontrar está aquí: What is the right way to wire together 2 javascript objects?. Parece un gran comienzo, pero pensé que sería capaz de encontrar algo con un historial de desarrollo más largo.

Solo he usado Castle Windsor yo mismo, y realmente me lo estoy perdiendo en el terreno del cliente web.

+0

Usted sólo puede tener las funciones cuyo nombre cambió en un archivo diferente, ¿por qué necesita un marco? –

+0

Hay mucho más que eso. En JasFac (ver mi respuesta), ni siquiera he empezado a arañar la superficie de lo que se puede/debería hacer. Es un gran tema. Normalmente, JavaScript tiende a utilizar patrones de estilo de Localizador de servicios, omitiendo por completo IoC –

+0

Algunas respuestas son de personas a las que les gusta IoC pero que en realidad no terminaron utilizando su solución. Me gustaría saber cómo se mantienen desacoplados sus objetos. ¿Usando un localizador de servicio? –

Respuesta

4

Empecé a escribir uno que nunca llegué a terminar. No estoy seguro si alguna vez lo haré ya que los gastos generales probablemente no valen la pena. si está interesado, es en: http://code.google.com/p/jasproject/wiki/JasFac (que es la parte de la COI, el conjunto completo está en http://code.google.com/p/jasproject/)

La biblioteca de burla es bastante completo (sin expectativas, sin embargo, por el momento sólo tiene que utilizar las afirmaciones sobre los burla de/talones) pero falta el marco de prueba de la unidad. La porción de IoC es bastante completa, pero podría tener algunos errores (aunque no lo creo)

Siéntase libre de utilizarlo y/o contribuir, lo puedo ayudar donde lo necesite.

EDIT: Más de uso se puede ver en las pruebas unitarias para jasfac: https://jasproject.googlecode.com/svn/trunk/Jas.Tests/JasFacTests.js

+1

¿Puede explicar por qué no lo necesitaba? –

+0

Bueno, como dije en el otro comentario, la mayoría de las personas usa localizadores de servicios para este tipo de necesidad en JS. Además, el tamaño de su JS realmente importa, por lo tanto, a menos que esté haciendo un cliente realmente grueso, querrá minimizar el mayor tamaño de código y computación posible. Ver http://video.yahoo.com/watch/1041101/3881103 –

4

que estaba buscando uno el año pasado y corrió a través de squirrel-ioc. Había algo que no me gustó: creo que solo admite instancias de estilo singleton.

ardilla es un contenedor de IoC implementado en Javascript para promover el mejor uso de la arquitectura y patrones en Javascript aplicaciones basadas en navegador

empecé a escribir mi cuenta y tengo bastante lejos (constructor y setter injection, valores y relaciones de referencia, soporte singleton, pruebas JsUnit) pero nunca realmente lo necesité en mi aplicación. Puede que tenga que ver el proyecto de Luke. Como referencia, aquí hay un ejemplo del formato de configuración con el que terminé.

var iocConfig = { 
    "a" : { Type : A }, 
    "b1" : { Type : B, Props : [{Name : 'Letter', Ref : "a"}] }, 
    "b2" : { Type : B, Props : [{Name : 'Letter', Val : "a"}] }, 
    "c2" : { Type : C, Args : [{Ref : "a"}, {Val : "a"}] }, 
    "d" : { Type : D, Props : [{Name : 'Letter', Ref : "a"}] }, 
    "date" : { Type : Date, Props : [{Name : 'FullYear', Val : 2008}, {Name : 'Month', Val : 0}, {Name : 'Date', Val : 1}] }, 
    "array3" : { Type : Array, Args : [{Val : 3}] }, 
    "number1" : { Type : Number, Args : [{Val : 1}] }, 
    "string1" : { Type : String, Args : [{Val : "1"}] }, 
    "s-true" : { Type : S, Singleton : true}, 
    "s-false" : { Type : S, Singleton : false} 
}; 
+0

Sí, yo tampoco era fanático de la ardilla, de ahí escribo la mía. Tuve la misma idea: comencé pero no tenía una necesidad real, así que nunca terminé. Mira la fuente mía, especialmente las pruebas unitarias, hay mucho más que puedes hacer con ella que con las formas del sitio. –

+4

¿Puede explicar por qué no lo necesitaba? –

0

En los lenguajes de tipos dinámicos como JavaScript y Ruby, DI no es realmente tan beneficiosa.

El principal beneficio de DI en lenguajes tipados estáticos, como Java, está en pruebas: para reemplazar la implementación real de algunas clases con una simulación. Eso es porque en Java las clases son inmutables y no puedes reemplazarlas fácilmente con burlas; necesitas todo un sistema DI para lograrlo.

Pero en JavaScript puede reemplazar fácilmente las clases/métodos existentes con los burlados. Entonces DI no es realmente necesario para lograr la capacidad de prueba.

Por supuesto, hay otras situaciones en las que DI podría ser útil, pero no ha señalado realmente para qué desea usar la DI, por lo que cubrí el caso más obvio.

+6

Creo que DI es diferente de IoC. Sí DI es fácil en Javascript, ya que puede escribir donde quiera, estoy usando DI actualmente para pruebas unitarias. Aunque DI es mucho más fácil en Javascript, creo que IoC aún podría tener ventajas en la documentación de dependencias y en la limpieza del código de prueba. En este momento, cuando pruebo algo, debo verificar manualmente que cada dependencia se haya reemplazado correctamente. Con IoC puede ver claramente qué dependencias existen y con qué se han reemplazado. –

+0

Buen punto Frank. –

+2

Estoy de paso, así que no tengo tiempo para buscar una referencia, pero DI no es solo para probar (ni siquiera es el beneficio principal). –

0

utilizo uno, aquí es simple código de especificaciones técnicas (es CoffeeScript):

di.register 'a', -> 'component a' 
di.get('a').should be: 'component a' 

También hay devoluciones de llamada, diferentes ámbitos (aplicación, ejemplo, personalizados), la capacidad de asignar explícitamente componentes .

DI: https://github.com/alexeypetrushin/rad_core/blob/master/assets/lib/dependency_injection.coffee

Spec: https://github.com/alexeypetrushin/rad_core/blob/master/assets/lib_spec/dependency_injection_spec.coffee

lo uso para montar aplicación Backbone.js, hay un montón de objetos (APP, Menú, Aviso, ...) y es que mi vida más fácil.

ADVERTENCIA: Yo lo uso internamente con objetos nativos alterados, por lo que puede haber algunos errores :) Por favor, hágamelo saber, probablemente lo solucione en un día o dos (enviando a través de la página de problemas https://github.com/alexeypetrushin/rad_core/issues).

P.S. ¿No te gusta el término COI de que sea demasiado amplia, DI es mucho más exacta definición.

0

Puede consultar esta sencilla biblioteca: fcjs Es muy pequeña pero puede ser muy útil para desacoplar su código. Está inspirado en el marco de Swiz AS3

0

Otra opción (más nueva) es requireJS (http://requirejs.org/).

+9

No nuevo, no IoC –

+1

Sí, otro tipo de administración de dependencias :) – jamiebarrow

+1

IoC realmente saca a relucir la pedantica. Es una opción válida. –

-1

Trate de infusión. Es un marco IoC JS bastante poderoso. Es utilizado por par de centros de investigación en las universidades de Toronto y Berkeley Infusion

página de GitHub del proyecto con más información puede ser encontrada aquí Infusion GitHub pages

1

Echa un vistazo invertido http://philmander.github.com/inverted/, una característica repleto de contenedores Javascript COI he creado . Se ejecuta en la parte superior de AMD en el navegador y también trabaja con el Nodo.

Utilizado en conjunto con AMD, Inverted usa un archivo de configuración separado para expresar cómo se instancian las clases y cómo interactúan. Una vez definidos estos valores predeterminados y relaciones, un contexto de aplicación se puede crear, y los casos de las clases puede ser utilizado.

http://dailyjs.com/2013/01/04/controldeck-xlsx-inverted/

0

Trate canDI.Es una biblioteca simple de inyección de dependencia y creación de objetos. Puede crear singletons, instancias y variables que se registran automáticamente en la creación.

https://github.com/bflemi3/canDI

Cuestiones relacionadas