MVC

[Edgar Ramos]

Siguiendo con el espiritu alnet quisiera preguntar lo siguiente, y
debido a que esta pregunta pueda no pertenecer a este foro pido
disculpas de antemano

Siguiendo AlNet Hispano y al grupo de NHibernate, me voy enterando de
muchas cosas que necesito saber para desarrollar una aplicacion
siguiendo los mejores estandares de la industria
por ejemplo (para mi todo esto es nuevo tema y el como usar su framework)

.- IoC, ID : Castle.Windsor y Service Locator
.- Test Unitarios y de Integracion : nunit y moq
.- Persistencia : NHIbernate
.- Si mi aplicacion es para la web : Se que debo utilizar framework
que implementen el patron MVC, cual elegir ?, porque ?, todo siguiente
con el pensamiento AlNet
.- De igual forma para Programacion Orientada a Aspectos ?
.- etc, etc, hay tanto que no creo haber empezado por el principio

Gracias a todos por sus sugerencias

[Gustavo Ringel]

y...las opciones son miles...de todos modos mis sugerencias

MVC: Monorail, ASP.NET MVC

AOP: Podes usar Castle Windsor, si te preocupa mucho la eficiencia podes usar PostSharp

etc etc? Aprender lenguajes dinamicos, ver porque los que escriben en algunos de ellos se rien de MVP, MVC e incluso de IoC :)

Gustavo.

2010/4/5 Edgar Ramos <eramo...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

[Diego Mijelshon]

Edgar,

Personalmente me gusta la visión de alt.net como una búsqueda constante de mejores herramientas y diseños, y no como algo normativo.

Es por eso que creo que más que tratar de incorporar semejante magnitud de conceptos todos a la vez, te conviene ir incorporandolos a tu diseño a medida que veas qué valor le pueden agregar al mismo.

De la misma forma, no me parece que haya una unica herramienta posible en cada categoría. A algunos les gusta Castle, a otros Spring. A unos les gusta nUnit y a otros xUnit.

Afortunadamente, está lleno de información libre sobre todas estas herramientas, por lo que lo mejor que podés hacer es empezar a leer y escribir :-)

De cualquier modo, y como punto de inicio, podés empezar mirando http://www.sharparchitecture.net/, que es una infraestructura completa usando una selección de las herramientas que mencionaste.

   Diego

2010/4/5 Edgar Ramos <eramo...@gmail.com>

[Edgar Ramos]

Gracias Gustavo, tu personalmente cual crees que son las fortalezas y
debilidades de Monorail, ASP.NET MVC, esta ultima es de Microsoft
verdad ?

El día 5 de abril de 2010 13:19, Gustavo Ringel
<gustavo...@gmail.com> escribió:

[Gustavo Ringel]

Monorail es un proyect mas maduro que ASP.NET MVC, pero probablemente por ser de Microsoft ASP.NET MVC va a ser mas adaptado, o sea que tenes una decision "politica" tambien al elegir uno u otro.

No tengo tanta experiencia en web como para darte una buena lista, yo he usado ASP.NET MVC principalmente para hacer proyectos pequeños y hace lo que necesito...

[Edgar Ramos]

Diego tienes mucha razon, sigo leyendo toda la informacion necesaria y
en la escritura poniendo en practica segun se avance con lo primero,
pero es bueno saber las experiencias de la gente y saber que estan
usando, con http://www.sharparchitecture.net/ justo la semana pasado
alguien me paso el link, y estoy en esas

Gracias por las sugerencias

El día 5 de abril de 2010 13:17, Diego Mijelshon
<di...@mijelshon.com.ar> escribió:

[Edgar Ramos]

Gustavo, con respecto a tu opinion, crees valida si se tratase de
NHibernate y Entity Framework ?, no conozco mucho de los dos, pero por
lo que he escuchado en las VAN's sobre ORM, a EF, le falta mucho,
creen ustedes que esta distancia bien marcada existe entre los dos
proyectos que se menciono Monorail y ASP.NET MVC ?

El día 5 de abril de 2010 13:32, Gustavo Ringel
<gustavo...@gmail.com> escribió:

[Gustavo Ringel]

Cual opinion? que se usara mas si es de Microsoft? Si, las herramientas creadas por microsoft tienen en general mas adeptos.

La idea en Alt.Net es elegir las herramientas que mas se adapten a tu forma de trabajo, o sea que la pertenencia a Microsoft de algo no debiera ser algo que te defina a favor o en contra de una tecnologia.

Respecto a le falta mucho que quiere decir? Trataste de hacer algo con EF y no fue suficiente para lo que querias hacer? o hacer algo sencillo se transformo en complicado?

Yo no he llegado a probar EF, porque me siento comodo con NH y no me he encontrado con trabas o limitaciones que me inviten por el momento a buscar otros ORM's. Quizas el soporte de LINQ puede ser llamativo para probar EF en el estado en que esta, pero lo que hay en NH me es suficiente por ahora para mi forma de trabajo.

Como te dijo Diego, elegir NH o Castle o ASP.NET MVC no es una buena eleccion de por si misma, depende de que problema tenes que resolver, que conocimientos tiene el grupo de trabajo, que tiempo tenes para desarrollar...

[Alberto Rodríguez]

Hola a todos,

No puedo hablar de NHibernate porque nunca lo he utilizado, pero sí he utilizado ASP.NET MVC y Entity Framework para un proyecto relativamente grande y puedo asegurar que nos ha servido para todo lo que hemos necesitado, sin inconvenientes mayores.

Ahora quiero probar IoC y otras cosas más. Para eso he estado viendo S#arp Architecture que viene con todo integrado, incluyendo NHibernate, Caste, ASP.NET MVC, etc. Lo que he visto hasta ahora está interesante, cuando lo pruebe para un proyecto real aportaré mis experiencias.

Ahora que estamos en eso, ¿alguien conoce otro Framework similar a Sharp Architecture, que incluya todo un stack completo, y si es posible que utilice ASP.NET MVC?

Saludos,

Alberto César Rodríguez Tejeda

2010/4/5 Gustavo Ringel <gustavo...@gmail.com>

[Daniel Cazzulino]

EF + WCF Data Services + Silverlight/AJAX (con un templating engine client-side) es una combinacion killer IMO.

MVC es un dolor de eggs... 

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

2010/4/5 Gustavo Ringel <gustavo...@gmail.com>

[Angel Java Lopez]

Oia, dolor de eggs... please, elaborate @kzu, give me more context... :-)

E pe que MVC es un dolor de eggs??
E pe que?

2010/4/5 Daniel Cazzulino <dan...@cazzulino.com>

[Edgar Ramos]

Angel me gustaria saber tu opinion al respecto

Mono Rails o ASP Net MVC

Gracias nuevamente

El día 5 de abril de 2010 14:32, Angel Java Lopez
<ajlop...@gmail.com> escribió:

[Daniel Cazzulino]

porq hoy en dia el 90% de los consumidores de tu server-side API son clientes rest (AJAX con JSON o Atom)

porq con MVC tenes q crear a mano tu API rest-compatible server-side

porq con MVC tenes q manualmente mantener la consistencia rest de tu API

porq con MVC rendereas "views" q son al pedo porq es preferible renderar las views client-side (perf, dinamismo, etc.)

porq con MVC tenes q crear exactamente lo mismo para cada entidad q tenes (si queres consistencia rest-like)

con EF + WCF Data Services tenes el mismo poder, con la consistencia *gratis*, y con todos los hooks q necesitas para pluggear tu custom biz logic y validacion q puedas necesitar.

y te hace JSON/Atom automaticamente.

exito mundial

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

2010/4/5 Angel Java Lopez <ajlop...@gmail.com>

[Cristian Prieto]

¿Y si la aplicación en cuestión representa o esta orientada a ese 10% restante?... 

Soy fiel defensor de NH, pero creo que si estas comenzando no te cae mal ni te hace daño darte una vuelta por la EF, razones? simple, en un par de años va a ser lo que la gran mayoría de desarrolladores van a saber usar/utilizar (así como lastimosamente 8 de cada 10 desarrolladores de la calle hoy por hoy saben usar a los horribles DataSets).

Acerca de todo lo demás, creo que el éxito es ir aprendiendo e incorporando las cosas poco a poco, vas a ver como luego todo lo que vas escuchando va cobrando sentido... es como un proceso de "iluminación" pero a "pasos" :D

En lo personal te diría que comenzaras aplicando cosas simples como control de versiones (hacerlo necesario e imprescindible para todo desarrollo que lleves, tan necesario como la compu en que trabajas) y aplicar luego conceptos de manejo de tu código fuente en tu VCS (aclaro, soy defensor acerrimo de DVCS, pero para principiantes no hay nada mejor que comenzar con uno *no* distribuido, quizás SVN). Luego comenzar a aplicar conceptos de TDD conforme avanzas en tu desarrollo, verás como luego "como arte de magia" muchas cosas que mencionan aquí (AOP, IoC, MVC, MVP, MVVM y otras cartas mágicas) cobraran sentido.

El camino es largo, pero ánimo, es divertido y la ruta panorámica realmente vale la pena!

PD: Si pudiera recomendarte leer algo, quizás te diría que comenzaras por algo como "The Pragmatic Programmer" o "Clean Code", valdran la pena, creeme!

PD2: Placer verlo por aquí don @kzu :D

Saludos,

2010/4/5 Daniel Cazzulino <dan...@cazzulino.com>

--
Cristian Prieto

[Daniel Cazzulino]

100% de acuerdo :)

Para endulzarte con lo q se puede hacer en 30' con EF y WCF Data Services: http://www.hanselman.com/blog/CreatingAnODataAPIForStackOverflowIncludingXMLAndJSONIn30Minutes.aspx

Y para los q sospechen q hay algo q no se pueda testear: http://blogs.msdn.com/adonet/pages/walkthrough-test-driven-development-with-the-entity-framework-4-0.aspx

Enjoy!

/kzu

PD: tratando de contribuir un poquito por aca tb :)

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

2010/4/5 Cristian Prieto <keme...@gmail.com>

[Carlos Peix]

Creo que varios de los puntos que señala kzu deben ser contextualizados. 

2010/4/5 Daniel Cazzulino <dan...@cazzulino.com>

porq hoy en dia el 90% de los consumidores de tu server-side API son clientes rest (AJAX con JSON o Atom)

porq con MVC tenes q crear a mano tu API rest-compatible server-side

porq con MVC tenes q manualmente mantener la consistencia rest de tu API

Esto es cierto en el "mundo kzu". No digo que no sea un mundo real, al contrario, pero hay otro mundo, creo que masivamente mas grande, en el que ese porcentaje bien podria invertirse. No me pidan que respalde mis afirmaciones con cifras, cada cual sabra.

 

porq con MVC rendereas "views" q son al pedo porq es preferible renderar las views client-side (perf, dinamismo, etc.)

Este es un buen punto pero no esta tan difundida aun esta tecnica (fuera del "mundo kzu"). Single page applicacions alla Google Mail definitivamente es un tema a tener en el radar y se basarian en esto que dice kzu. Vean [1].

 

porq con MVC tenes q crear exactamente lo mismo para cada entidad q tenes (si queres consistencia rest-like)

Mmmm, "entidad based pprogramming no es mi estilo". Nunca "hago lo mismo" para todas las entidades, por lo tanto esta caracteristica no es ni mala ni buena para mi.

 

con EF + WCF Data Services tenes el mismo poder, con la consistencia *gratis*, y con todos los hooks q necesitas para pluggear tu custom biz logic y validacion q puedas necesitar.

Hooks para la logica de negocios? No, gracias. Para mi la logica de negocios es lo principal, los hooks son para los cross cutting concerns. Cuando la logica de negocios es un cross cutting concern que se "hookea" no me gusta. Sera que me estoy poniendo viejo.

y te hace JSON/Atom automaticamente.

exito mundial

:-), ya escuche eso antes...

Con respecto a lo que planteaste en el ultimo post:

<kzu>

Para endulzarte con lo q se puede hacer en 30' con EF y WCF Data Services: http://www.hanselman.com/blog/CreatingAnODataAPIForStackOverflowIncludingXMLAndJSONIn30Minutes.aspx

Y para los q sospechen q hay algo q no se pueda testear: http://blogs.msdn.com/adonet/pages/walkthrough-test-driven-development-with-the-entity-framework-4-0.aspx

</kzu> 

Uuuuhhhh, wizzard based programming? no gracias, a mi no me gusta.

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[1] http://javascriptly.com/2009/12/coremvc-an-jquery-based-mvc-framework/

----------------------------------
Carlos Peix

[Daniel Cazzulino]

porq hoy en dia el 90% de los consumidores de tu server-side API son clientes rest (AJAX con JSON o Atom)

porq con MVC tenes q crear a mano tu API rest-compatible server-side

porq con MVC tenes q manualmente mantener la consistencia rest de tu API

Esto es cierto en el "mundo kzu". No digo que no sea un mundo real, al contrario, pero hay otro mundo, creo que masivamente mas grande, en el que ese porcentaje bien podria invertirse. No me pidan que respalde mis afirmaciones con cifras, cada cual sabra.

puede ser. pero no estamos hablando de apps ya funcionando. esas tienen un mix inevitable.

para "green field", yo creo q ni lo pensaria demasiado... el cliente siempre va a querer "algo de AJAX, como GMail y Google Reader, viste?" ;)

 

porq con MVC tenes q crear exactamente lo mismo para cada entidad q tenes (si queres consistencia rest-like)

Mmmm, "entidad based pprogramming no es mi estilo". Nunca "hago lo mismo" para todas las entidades, por lo tanto esta caracteristica no es ni mala ni buena para mi.

Aclaro mi punto: para cada entitidad q es un aggregate root, quise decir ;)

Que cosas haces distinto para cada una de ellas? No aplicas validacion siempre, por ej.? No las accedes via un service? (en MVC rendereando json, ese es efectivamente su service).

 

con EF + WCF Data Services tenes el mismo poder, con la consistencia *gratis*, y con todos los hooks q necesitas para pluggear tu custom biz logic y validacion q puedas necesitar.

Hooks para la logica de negocios? No, gracias. Para mi la logica de negocios es lo principal, los hooks son para los cross cutting concerns. Cuando la logica de negocios es un cross cutting concern que se "hookea" no me gusta. Sera que me estoy poniendo viejo.

Entiendo entonces q tu preferencia es por rich domain objects. Como integras eso con algo como EF? Partial classes con el behavior? 

A mi me gusta el command/query separation (http://martinfowler.com/bliki/CommandQuerySeparation.html), hace q tu logica sea mas escalable, en vez de terminar con un Customer q hace desde comprar cosas hasta hacerte reclamos, cargar bugs y recibir regalos de navidad :P. La ventaja tambien es q se alinea muy bien con la separacion en Astoria (WCF Data Services) entre query interceptors y change interceptors (los primeros serian los query y los segundos los commands).

En esa perspectiva, la logica de negocios es una capa sobre la de entidades, y q puede ser invocada desde cualquier lado, incluso desde las operaciones REST de un webservice de astoria. Para ponerlo mas concreto:

[ChangeInterceptor("Purchases")]

public void OnPurchase(IPurchase purchase, UpdateOperations operations)

{

if (operations == UpdateOperations.Add)

{

            // Llamas a la logica dependiendo de la operacion, por ej:

            new AddPurchaseCommand(purchase).Execute();

            // o (esto puede ser un metodo definido en la partial interface, o incluso un extension method)

            purchase.Create();

}

 

Con respecto a lo que planteaste en el ultimo post:

<kzu>

Para endulzarte con lo q se puede hacer en 30' con EF y WCF Data Services: http://www.hanselman.com/blog/CreatingAnODataAPIForStackOverflowIncludingXMLAndJSONIn30Minutes.aspx

Y para los q sospechen q hay algo q no se pueda testear: http://blogs.msdn.com/adonet/pages/walkthrough-test-driven-development-with-the-entity-framework-4-0.aspx

</kzu> 

Uuuuhhhh, wizzard based programming? no gracias, a mi no me gusta.

nonononono. esto es *model*-based programming. 

si queres niveles de productividad mayores a los q podes lograr escribiendo a mano el mundo, es un camino muy viable.

yo iria pidiendo conocimientos de T4 en las entrevistas laborales ;)

 

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[1] http://javascriptly.com/2009/12/coremvc-an-jquery-based-mvc-framework/

----------------------------------
Carlos Peix

--

[Carlos Peix]

Interesante, veamos...

2010/4/7 Daniel Cazzulino <dan...@cazzulino.com>

porq hoy en dia el 90% de los consumidores de tu server-side API son clientes rest (AJAX con JSON o Atom)

porq con MVC tenes q crear a mano tu API rest-compatible server-side

porq con MVC tenes q manualmente mantener la consistencia rest de tu API

Esto es cierto en el "mundo kzu". No digo que no sea un mundo real, al contrario, pero hay otro mundo, creo que masivamente mas grande, en el que ese porcentaje bien podria invertirse. No me pidan que respalde mis afirmaciones con cifras, cada cual sabra.

puede ser. pero no estamos hablando de apps ya funcionando. esas tienen un mix inevitable.

para "green field", yo creo q ni lo pensaria demasiado... el cliente siempre va a querer "algo de AJAX, como GMail y Google Reader, viste?" ;)

Bueno, hay muchas empresas, las que desarrollan un producto, que viene de Fox4Windows, que vienen de Fox4Dos, que vienen de Clipper, etc, no siempre hacen lo que quiere el cliente, hacen lo que quiere el product manager (al que le imprimen los mails porque no entiende el Outlook Express). Si ajaxizan alo lo hacen como pueden y si se puede.

 

 

porq con MVC tenes q crear exactamente lo mismo para cada entidad q tenes (si queres consistencia rest-like)

Mmmm, "entidad based pprogramming no es mi estilo". Nunca "hago lo mismo" para todas las entidades, por lo tanto esta caracteristica no es ni mala ni buena para mi.

Aclaro mi punto: para cada entitidad q es un aggregate root, quise decir ;)

Que cosas haces distinto para cada una de ellas? No aplicas validacion siempre, por ej.? No las accedes via un service? (en MVC rendereando json, ese es efectivamente su service).

Si, me imaginaba que entidades eran aggregates. Igual, no accedo a aggregates para hacer un CRUD sobre ellas, incluso, no es raro que una operacion puede afectar a mas de una.

 

con EF + WCF Data Services tenes el mismo poder, con la consistencia *gratis*, y con todos los hooks q necesitas para pluggear tu custom biz logic y validacion q puedas necesitar.

Hooks para la logica de negocios? No, gracias. Para mi la logica de negocios es lo principal, los hooks son para los cross cutting concerns. Cuando la logica de negocios es un cross cutting concern que se "hookea" no me gusta. Sera que me estoy poniendo viejo.

Entiendo entonces q tu preferencia es por rich domain objects. Como integras eso con algo como EF? Partial classes con el behavior? 

EF? no, hasta que no entiendan que el centro del mundo no es el ORM no creo que pueda usarlo. Si hasta escuche que ahora anda dando vueltas un generador de modelo a partir de la metadata de EF :-P. It's the other way around baby.

 

A mi me gusta el command/query separation (http://martinfowler.com/bliki/CommandQuerySeparation.html), hace q tu logica sea mas escalable, en vez de terminar con un Customer q hace desde comprar cosas hasta hacerte reclamos, cargar bugs y recibir regalos de navidad :P. La ventaja tambien es q se alinea muy bien con la separacion en Astoria (WCF Data Services) entre query interceptors y change interceptors (los primeros serian los query y los segundos los commands).

Seee, definitivamente me gustan los comandos. Query separation, cuando hace falta (en muchos casos no lo necesite). Solo alinea con Astoria si tus comand/queries mapean uno a uno con tus aggregates. Si no estas en problemas. Mis commands pueden hasta tener una smantica distinta a los aggregates.

 

En esa perspectiva, la logica de negocios es una capa sobre la de entidades, y q puede ser invocada desde cualquier lado, incluso desde las operaciones REST de un webservice de astoria. Para ponerlo mas concreto:

Sep, conozco el modelo. No lo uso, no me cierra tener dos categorias de objetos del modelo (entidades y logica). Te acordas de Business Entities y Business Componentes?

 

[ChangeInterceptor("Purchases")]

public void OnPurchase(IPurchase purchase, UpdateOperations operations)

{

if (operations == UpdateOperations.Add)

{

            // Llamas a la logica dependiendo de la operacion, por ej:

            new AddPurchaseCommand(purchase).Execute();

            // o (esto puede ser un metodo definido en la partial interface, o incluso un extension method)

            purchase.Create();

}

Mmmm, no soy capaz de digerir esto, no entiendo bien el contexto.

 

 

Con respecto a lo que planteaste en el ultimo post:

<kzu>

Para endulzarte con lo q se puede hacer en 30' con EF y WCF Data Services: http://www.hanselman.com/blog/CreatingAnODataAPIForStackOverflowIncludingXMLAndJSONIn30Minutes.aspx

Y para los q sospechen q hay algo q no se pueda testear: http://blogs.msdn.com/adonet/pages/walkthrough-test-driven-development-with-the-entity-framework-4-0.aspx

</kzu> 

Uuuuhhhh, wizzard based programming? no gracias, a mi no me gusta.

nonononono. esto es *model*-based programming. 

si queres niveles de productividad mayores a los q podes lograr escribiendo a mano el mundo, es un camino muy viable.

yo iria pidiendo conocimientos de T4 en las entrevistas laborales ;)

Concedo, pero en las entrevistas busco gente inteligente, todo lo demas, se aprende. Acordate de todas las tecnologias que pasaron (no solo de MS) y los sistemas todavia corren.

 

 

/kzu

Abrazo

----------------------------------
Carlos Peix
 

[Daniel Cazzulino]

Que te puedo decir, querido Carlos.

En una sola frase: Time To Market.

ORM, models, codegen, databinding, apunta a q tengas algo en el mercado, util y con funcionalidad valiosa para el cliente, en el menor tiempo posible.

En un proyecto actual donde estoy usando EF + WCF Data Service puedo decirte q me permite enfocarme en el valor agregado, pensar en mis entidades y sus relaciones, sin pensar en la DB (uso un Database Project q me actualiza la DB sola) y en la logica sobre esas entidades. Hay un porcentaje sorprendente de logica q se puede aplicar en acciones REST sobre tus entidades. Una vez q haces el switch de "custom operations" a "REST operations" sobre tus entities, te das cuenta en realidad de q tu logica q no encuadra en ese modelo es en realidad la excepcion, no la regla.

Tirame ejemplos concretos y te trato de convencer ;)

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

2010/4/7 Carlos Peix <carlo...@gmail.com>

--

[Angel Java Lopez]

Hola gente!

Algun comentario rapido, antes de la ducha:

Teniendo una Service Layer, si por abajo tenemos Business Entities, y Busines Components, o algo similar o alejado, o un Domain Model, es lo mismo para quienes consuman esa Service Layer. Es mas, lo pondria como "prueba acida" de tener aislado la implementacion final del negocio.

Habra que ver que poner en la Service Layer. Pueden poner llamadas separadas en Commands y Queries, operaciones alineadas con REST,  operaciones que por abajo "patean y hacen trabajar" al Domain Model, etc..

Y coincido con @kzu: es model-based ese tipo de generacion de codigo. Es lo mismo que hacen los compiladores desde hace decadas: pasar de un modelo, expresado en un lenguaje, a otro. Y hasta diria que tiene como consecuencia: abstraer y pensar mas, llegar realmente a lo esencial de lo que tenemos entre manos, en vez de estar en las technicalities. No siempre se llega hasta ese punto final, pero veo que cualquier planteamiento de modelo permite acercarse a eso. Y para eso, hace falta gente pensante.

Por poner una analogia, es lo que paso con la historia de las matematicas: sacar de cosas interesantes, practicas, otras mas interesantes, mas depuradas, destiladas, lo que permitio separar lo realmente importante de cada caso. Desde las operaciones con numeros, llegamos asi a la teoria de grupos, anillos, modulos, cuerpos, y la teoria de categorias.

No quisiera recargar las tintas, pero quisiera, para dejar sentado que trabajar con modelo implica justamente contratar gente pensante, tirar esta afirmacion exagerada a proposito: sin modelo y con modelo, es la misma diferencia entre un calculista egipcio que conoce hacer calculos, y un matematico, que sabe ver mas alla, que conoce las propiedades de una estructura de cuerpo, luego, que opere con reales, complejos, que le quite algo y trabaje con modulos, anillos, etc...

Por ejemplo, Evans, con su libro, practicamente propone un Metamodelo, como deben ser hechos nuestros modelos. Se podria, por abajo, pasar de gran parte de nuestro modelo, a codigo que elijamos como generar, que resuelva gran parte de los detalles, y deje claramento separado lo que tenemos que ir extendiendo o armando nosotros. Una prueba acida para eso: saber que podemos cambiar las implementaciones de codigo generado, sin tocar el modelo que hemos descubierto. Justamente, me esta pasando ahora en una aplicacion real. El modelo sigue igual, cambiamos varios detalles de implementacion. La logica del negocio, se sigue agregando en los mismos lugares, las interfaces de usuario se siguen armando cerca del usuario y cliente final, lo demas, sigue siendose generado desde el modelo. Hasta tengo la confianza de si quisiera cambiar de persistencia, lenguaje de programacion, MVP o MVC o PiruloView, ORM y otras cosas, podria sobrevivir el modelo, generar lo automatico de nuevo, solo tendria que migrar lo manual. Me cambian de PitutoFramework 2.0 a 3.0? Sigo generando del modelo lo que ese 3.0 necesita. Resulta ahora que para resolver como pirifilar los rembos, XSuperDuperLibrary es mejor? La adopto, tal vez no para este proyecto X, pero para aquel Y que tengo entre manos...

Tambien, una vez logrado un modelo, permite al equipo concentrarse en otras cosas, tal vez, la mas interesantes de un desarrollo en particular.

O sea: tener un modelo, y generar a partir de ahi, permite:
- Tener gente pensante que realmente quiera llegar al quid de las cuestiones
- Tener herramientas que permitan que proyectos particulares X1, Y2, etc... vean aliviado el trabajo con las technicalities
- Tener gente que quiera mas trabajar en lo particular de cada proyecto
- Poder ir aislandome, poco a poco, no necesariamente todo de golpe, de los cambios en las tecnologias, lenguajes, etc...
- Permite encapsular en el proceso de generacion de codigo desde un modelo, mejores practicas, patrones... Ese proceso que va desde el modelo, hasta el codigo final (que NO ES TODA la aplicacion), termina siendo un sistema experto, resultado de destilar el conocimiento y las habilidades de un grupo de expertos.

Hasta vislumbro el tiempo que llegue el momento que programar sin modelo, sea visto como programar en assembler... si, esta bueno, pero... ;-)

Y bueno, @kzu, en vez de T4 les pediria otro lenguaje... ejem... ;-) (ya parezco Fabio Maulo, espero que todos entiendan esta frase sin contexto ;-) (cualquier cosa preguntan a que me estaba refiriendo)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

2010/4/8 Daniel Cazzulino <dan...@cazzulino.com>

[Carlos Peix]

Estimado,

Al menos me sembraste una duda, voy a mirar para ese lado. No vamos a aburrir a nuestra audiencia con una competencia de ejemplos, el convencimiento a mi (y seguramente a vos tambien) me llega por el lado de leer, probar, errar, probar y asi siguiendo hasta que junto una respetable cantidad de pros y cons para decidir. Igual te agradezco la oferta. Ya nos cruzaremos en algun Oepn Space para debatir.

Por ultimo, solo quise atemperar/balancear tu propuesta ante la pregunta de nuestro colega Edgar, que recien se asoma a este mundo.

Gracias

2010/4/8 Daniel Cazzulino <dan...@cazzulino.com>

Que te puedo decir, querido Carlos.

En una sola frase: Time To Market.

ORM, models, codegen, databinding, apunta a q tengas algo en el mercado, util y con funcionalidad valiosa para el cliente, en el menor tiempo posible.

En un proyecto actual donde estoy usando EF + WCF Data Service puedo decirte q me permite enfocarme en el valor agregado, pensar en mis entidades y sus relaciones, sin pensar en la DB (uso un Database Project q me actualiza la DB sola) y en la logica sobre esas entidades. Hay un porcentaje sorprendente de logica q se puede aplicar en acciones REST sobre tus entidades. Una vez q haces el switch de "custom operations" a "REST operations" sobre tus entities, te das cuenta en realidad de q tu logica q no encuadra en ese modelo es en realidad la excepcion, no la regla.

Tirame ejemplos concretos y te trato de convencer ;)

/kzu

----------------------------------
Carlos Peix 

[Carlos Peix]

Hola Angel,

Estoy de acuerdo con vos en la mayoría de tus párrafos.

En el párrafo que comenzas mencionando a Evans, hablas de un modelo, que, a menos que me haya perdido algún post reciente, incluye la estructura de tus entidades (o aggregates). De esta forma, lo que no digiero es que la lógica "se agregue" al modelo, como sugiere esta frase del mismo párrafo: "La lógica del negocio, se sigue agregando en los mismos lugares,...".

Ya hice mis palotes en ese enfoque y todavia no junto suficientes pros para contrarrestar los cons. Esto, por otra parte, puede ser fruto de mi impericia ya largamente demostrada, pero es lo que hay :-).

Como siempre, seguiré alerta.

Gracias

2010/4/8 Angel Java Lopez <ajlop...@gmail.com>

----------------------------------
Carlos Peix 

[Angel Java Lopez]

Hola gente!

Carlos, en ese mensaje no hago referencia a un modelo mio. El de varios de mis posts, por ejemplo, nacio antes que la publicacion de Evans. Se llama Entity casi de casualidad (mas influido indirectamente, por Entity Beans de Enterprise JavaBeans).

A lo que iba que uno puede modelar incluso eso que propone Evans, en un modelo que no sea de codigo. Yo propugno:

Modelo(s) ---> Procesos varios de transformacion --> Codigo (parte de la aplicacion, en general)

(pongo posiblemente Modelos, porque puede haber un modelo de dominio, un modelo que explique cosas de la base de datos, o de las convenciones de mapeo, o de los servicios a exponer)

Tambien propugno que cada grupo se arme el modelo que mas le convengan. E ir refinandolo de manera agil. Si quieren modelar entidades y value objects, bien. Si quieren modelar rembos, pitutos y pirifiladores neumaticos, bien tambien.

Tambien propugno que se parta de un ejemplo de aplicacion donde la empresa, grupo, equipo, se sienta comoda. Y de ahi abstraer, para poder usar ese conocimiento en nuevas aplicaciones. Si una empresa de software hace software para otras empresas, tanto si tiene una linea de negocios, como si cada aplicacion es distinta, se beneficiara de tomar un caso de exito, abstraer las decisiones claves que se tomaron, y encapsularlo para que un sistema experto, partiendo de un modelo, sepa como generar codigo que solucione problemas tecnologicos.

Muchas librerias de programacion, toman un camino parecido, pero sin querer desligarse del lenguaje y de la plataforma. Solucionan un problema tecnologico, con codigo. Pero son para tal framework (p.ej. .NET y no Java). Como frameworks y librerias salen todos los dias (siempre hay un hindu o chino que no tiene novia, y se arma un MVC para Clojure o lo que venga), partiendo de un modelo mas abstracto, la empresa puede ir abstrayendose de los "fashion" del momento. Habra, en la empresa, un Jose Oracle especialista en el tema, y encapsularemos gran parte de su conocimiento en el sistema experto. Y asi en otros temas.

Pero independientemente de usar Java, JavaServerPages, JavaServer Faces, Struts 2.x, Telerik ORM, NHibernate, iBatis, MVC, MonoRails, ASP.NET MVC 1,2,3,quiensabecuandoparandeversionar, Hibernate, ADO.NET, Stored Procedures, Oracle, o SQLServer, MySql, Postgress, quichicientos archivos de configuracion, algunos embebidos, lineas interminables de FluentX, que solo las entienden los que escribieron eso, XAML, Silverlight, otras tecnologias RIAs, atributos que no hay que olvidar de poner, serializadores JSon, serializadores BSon, seguridad en archivos de configuracion WCF, JQuery, Ruby, Python, Sinatra, Clojure, Scala, Java 7, si adopto Evans, CQRS, Business Entities/Businnes Components, o MiMetodoQueLoHiceEnCasaYMeSientoComodo, y si quieren sigo.... independientemente de todo eso, la empresa sigue, por anios, construyendo sistemas, digamos financieros, o del mercado vertical que elija.

Y hasta podemos compartir modelos y soluciones, mas alla de la empresa, para ir aprendiendo entre todos. No ser como Fermat: escribir "si, tengo una solucion... pero que se yo.. .me la guardo... " :-)

En cuanto a agregar la logica de negocios, me ha resultado que, dependiendo del estilo que se adopte, por ejemplo, Business Entities vs Business Components, o Dominio a la Evans, siempre hasta ahora he podido dejar todo como para que la logica se agregue en los lugares previstos. Si, por ejemplo, trabajando en equipo, alguien quiere agregar logica a una entidad, lo escribe ahi, y en cualquier regeneracion de codigo a partir del modelo, esa parte se respeta.

Podria modelar hasta la logica, pero no he visto que ese camino sea tan necesario. La gente se encuentra mejor en ese punto, y hasta sirve para que el equipo vaya entendiendo mas sobre el sistema que esta armando, mas sobre la realidad que quiere reflejar. El modelo los libera de otras cosas: estar pensando en como pongo tal cosa en un archivo de configuracion para tal libreria, y no olvidarme de agregar tal otro atributo que necesita tal libreria, o tal parametro en tal stored procedure, y todo eso que hace que tengamos que tener cuarenta ojos abiertos. Oia... como con assembler... ;-)

En cuanto a tu experiencia sobre la logica de negocios y relacionados, algun post?

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

2010/4/8 Carlos Peix <carlo...@gmail.com>

--

[Daniel Calvin]

Hola gente

Solo un comentario, algo que me pica desde hace mucho, así que .. que mejor que rescarme...

Angel escribe:

A lo que iba que uno puede modelar incluso eso que propone Evans, en un modelo que no sea de codigo. Yo propugno:

Modelo(s) ---> Procesos varios de transformacion --> Codigo (parte de la aplicacion, en general)

(pongo posiblemente Modelos, porque puede haber un modelo de dominio, un modelo que explique cosas de la base de datos, o de las convenciones de mapeo, o de los servicios a exponer)

También propugno que cada grupo se arme el modelo que mas le convengan. E ir refinándolo de manera ágil. Si quieren modelar entidades y value objects, bien. Si quieren modelar rembos, pitutos y pirifiladores neumaticos, bien tambien.

Y me alegra, la base del paradigma de objetos es la simulación y crear abstracciones de aquello que conforma o interviene en ese mundo a simular (y relaciones entre esas abstracciones) , el problema a resolver. Esa abstracción/es se basará/n en la observación del problema en el mudo real , ( el del dominio del problema ) y en definitiva aunque las abstracciones no sean la cosa real, las representan. El conjunto de esto es el modelo de dominio de un problema X.

Por que el comentario? Simplemente porque pareciera muchas veces que hablar de dominio, modelo, etc, es algo que surgió en la ultima década a mas o menos y mas allá de la arquitectura o metodología a adoptar la realidad que son conceptos que en su concepción tienen treinta y pico de años....

Les pido disculpas, seguro no aporta, pero es como una especie de catarsis... es como que me revelo un poco al sinónimo automático Evans // Domain Model, cosas de viejo....

Saludos

Daniel Calvin

--
Daniel A. Calvin
Cooperator Team Member
http://www.cooperator.com.ar
Microsoft Certified Professional

[Angel Java Lopez]

Loosely related, pero interesante hilo de comentario, sobre time to market y otras yerbas:

http://blog.objectmentor.com/articles/2010/04/06/20-more-bugs-or-20-less-features

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

2010/4/8 Daniel Cazzulino <dan...@cazzulino.com>

Que te puedo decir, querido Carlos.

En una sola frase: Time To Market.

ORM, models, codegen, databinding, apunta a q tengas algo en el mercado, util y con funcionalidad valiosa para el cliente, en el menor tiempo posible.

....

[Cristian Prieto]

So far una de las mejores discusiones que he leido en las últimoas semanas en Alt.Net Hispano :D

Por eso nos los cambio! :P

2010/4/8 Angel Java Lopez <ajlop...@gmail.com>

Loosely related, pero interesante hilo de comentario, sobre time to market y otras yerbas:

--
Cristian Prieto

[Edgar Ramos]

Concuerdo 100%, me he alimentado de informacion con todo lo expuesto

Sres. Muchas Gracias

[Daniel Cazzulino]

Y obviamente q un EF model no es el fin ni el climax de herramientas de modelado, por supuesto.

Lo interesante es que cuando hay codegen en base a modelos, cuando encontras un bug, lo fixeas en el template de transformacion (i.e. T4) y chau, lo fixeaste para todo el dominio ;)

salute!

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

2010/4/8 Edgar Ramos <eramo...@gmail.com>

[Carlos Peix]

Creo que estamos de acuerdo en los conceptos, pienso que elegimos maneras distintas de escribir el modelo, yo me siento mas comodo con los lenguajes tradicionales, abstrayendolos de las tecnologias. Aun no me sale hacer eso declarativamente.

Y no, no tengo posts, creo que debo decir: I'm canuto

Gracias

----------------------------------
Carlos Peix

[Carlos Peix]

Estimado kzu,

Y porque no puede hacerse eso con NH sin codegen [1]? Si encontras un bug, lo solucionas en NH y listo. Resultado equivalente.

A mi no me ha resultado tan trivial encontrar un bug en codigo generado, mucho menos editar los templates para corregirlo. Y juro que lo hice, no lo digo por opiniones prestadas.

[1] Yo sostengo que NH genera codigo, solo que lo genera "a runtime", como dice el Tano "mita spagnuolo, mita italiano".

----------------------------------
Carlos Peix

2010/4/8 Daniel Cazzulino <dan...@cazzulino.com>

[Carlos Peix]

Debate estimado Prieto, debate :-)

----------------------------------
Carlos Peix

2010/4/8 Cristian Prieto <keme...@gmail.com>

[Daniel Cazzulino]

El tiempo en q se haga el codegen es irrelevante (runtime o design-time) asi como la tecnica para generarlo (reflection.emit, intercepcion via dynamicproxy, o T4 templates).

Lo relevante es el nivel de abstraccion. Un modelo te permite visualizar y laburar a un nivel un cacho mas arriba q el codigo escrito a mano. 'ta claro q en algo como un "entity model" la abstraccion es como mucho leve (es un visualizer sobre lo q ya te da el object browser, digamos), pero igualmente util y productiva (agregar y remover entidades, renombrar, re-asociar, agregar y remover properties, etc. es algo q podes hacer en 5', mientras q con codigo termina llevando mucho mas tiempo). 

El valor para mi esta en q podes iterar mas rapido el disenio de tus entidades (en el caso concreto de EF) sin pensar tanto en las lineas de codigo q vas a tener q cambiar (refactors solo te ayudan hasta ahi no mas...)

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

2010/4/8 Carlos Peix <carlo...@gmail.com>

[Carlos Peix]

Interlineado,

2010/4/9 Daniel Cazzulino <dan...@cazzulino.com>

El tiempo en q se haga el codegen es irrelevante (runtime o design-time) asi como la tecnica para generarlo (reflection.emit, intercepcion via dynamicproxy, o T4 templates).

Exacto, exacto. No existe la dicotomía "con codigo generado" / "sin codigo generado". La diferencia esta en cuando se genera el codigo. Yo, particularmente, tengo preferencia, para la persistencia, por el codigo (SQL) generado en runtime por varios motivos.

 

Lo relevante es el nivel de abstraccion. Un modelo te permite visualizar y laburar a un nivel un cacho mas arriba q el codigo escrito a mano. 'ta claro q en algo como un "entity model" la abstraccion es como mucho leve (es un visualizer sobre lo q ya te da el object browser, digamos), pero igualmente util y productiva (agregar y remover entidades, renombrar, re-asociar, agregar y remover properties, etc. es algo q podes hacer en 5', mientras q con codigo termina llevando mucho mas tiempo).

A mi me pasa, generalmente, que los cambios en los modelos no son solo estructurales (asociaciones, composiciones, etc.). Creo que hay dos tipos de codigo en un modelo, aquel necesario para definir la estructura (referencias, colecciones, etc) y el codigo que define el comportamiento.

En mi experiencia, el primero es facil de modelar y generar, el segundo no tanto. Me queda claro que cada uno valora en forma distinta esto dependiendo de que proporcion de cada uno tiene. Yo tengo mucho del segundo y, ademas, lo considero el mas importante, donde pongo las neuronas.

 

El valor para mi esta en q podes iterar mas rapido el disenio de tus entidades (en el caso concreto de EF) sin pensar tanto en las lineas de codigo q vas a tener q cambiar (refactors solo te ayudan hasta ahi no mas...)

Iden anterior, los refactorings le pegan mas a mi codigo de comportamiento que al estructural, por esto es que le asigno menos importancia a automatizar el codigo que define estructura en el modelo.

 

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

Abrazo

----------------------------------
Carlos Peix

[listas q]

Hola,

> porq hoy en dia el 90% de los consumidores de tu server-side API son clientes rest (AJAX con JSON o Atom)

se podrá conseguir algo de info respaldando esto ?

> porq con MVC tenes q crear exactamente lo mismo para cada entidad q tenes (si queres consistencia rest-like)

no tengo idea de ASP.NET MVC, pero si es exactamente lo mismo entonces
no sería fácil generar esto automáticamente ? rails por nombrar un
framework MVC es REST automáticamente...cada entidad que creas ya es
REST, me imagino que en ASP.NET si no lo ponen en alguna versión
futura se podrá generar facilmente, o no ?

> para "green field", yo creo q ni lo pensaria demasiado... el cliente siempre va a querer "algo de AJAX, como GMail y Google Reader, viste?" ;)

Entiendo que si lo que quiere es "algo de AJAX" entonces no necesito
que sea todo REST, ni siquiera todo JSON, en todo caso podría
agregarlo para las entidades que lo necesito o quizás ni siquiera eso
dependiendo de los requerimientos que tenga ?

> EF + WCF Data Services + Silverlight/AJAX

tampoco tengo ni idea de Silverlight, pero no sufre de los mismos
problemas que Flash ? No es SEO friendly, no tiene deep linkink, no
tiene accesibilidad (WAI, section 508), etc.
(pero a diferencia de Flash no tiene encima la contra de que está
instalado en un porcentaje muy pequeño de computadoras ?)

Cualquier información sobre este último punto es más que bien
recibida.

Muy buena la discusión, gracias por aportar tan buena info.

Saludos,

Quique

On 5 abr, 15:27, Daniel Cazzulino <dan...@cazzulino.com> wrote:
> EF + WCF Data Services + Silverlight/AJAX (con un templating engine
> client-side) es una combinacion killer IMO.
>
> MVC es un dolor de eggs...
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> 425.329.3471
>

> 2010/4/5 Gustavo Ringel <gustavo.rin...@gmail.com>

>
>
>
> > Cual opinion? que se usara mas si es de Microsoft? Si, las herramientas
> > creadas por microsoft tienen en general mas adeptos.
> > La idea en Alt.Net es elegir las herramientas que mas se adapten a tu forma
> > de trabajo, o sea que la pertenencia a Microsoft de algo no debiera ser algo
> > que te defina a favor o en contra de una tecnologia.
>
> > Respecto a le falta mucho que quiere decir? Trataste de hacer algo con EF y
> > no fue suficiente para lo que querias hacer? o hacer algo sencillo se
> > transformo en complicado?
>
> > Yo no he llegado a probar EF, porque me siento comodo con NH y no me he
> > encontrado con trabas o limitaciones que me inviten por el momento a buscar
> > otros ORM's. Quizas el soporte de LINQ puede ser llamativo para probar EF en
> > el estado en que esta, pero lo que hay en NH me es suficiente por ahora para
> > mi forma de trabajo.
>
> > Como te dijo Diego, elegir NH o Castle o ASP.NET MVC no es una buena
> > eleccion de por si misma, depende de que problema tenes que resolver, que
> > conocimientos tiene el grupo de trabajo, que tiempo tenes para
> > desarrollar...
>
> > Gustavo.
>

> > 2010/4/5 Edgar Ramos <eramose...@gmail.com>

>
> >> Gustavo, con respecto a tu opinion, crees valida si se tratase de
> >> NHibernate y Entity Framework ?, no conozco mucho de los dos, pero por
> >> lo que he escuchado en las VAN's sobre ORM, a EF, le falta mucho,
> >> creen ustedes que esta distancia bien marcada existe entre los dos
> >> proyectos que se menciono Monorail y ASP.NET MVC ?
>
> >> El día 5 de abril de 2010 13:32, Gustavo Ringel

> >> <gustavo.rin...@gmail.com> escribió:

> >> > Monorail es un proyect mas maduro que ASP.NET MVC, pero probablemente
> >> por
> >> > ser de Microsoft ASP.NET MVC va a ser mas adaptado, o sea que tenes una
> >> > decision "politica" tambien al elegir uno u otro.
> >> > No tengo tanta experiencia en web como para darte una buena lista, yo he
> >> > usado ASP.NET MVC principalmente para hacer proyectos pequeños y hace
> >> lo que
> >> > necesito...
> >> > Gustavo.
>

> >> > 2010/4/5 Edgar Ramos <eramose...@gmail.com>

>
> >> >> Gracias Gustavo, tu personalmente cual crees que son las fortalezas y
> >> >> debilidades de Monorail, ASP.NET MVC, esta ultima es de Microsoft
> >> >> verdad ?
>
> >> >> El día 5 de abril de 2010 13:19, Gustavo Ringel

> >> >> <gustavo.rin...@gmail.com> escribió:

> >> >> > y...las opciones son miles...de todos modos mis sugerencias
> >> >> > MVC: Monorail, ASP.NET MVC
> >> >> > AOP: Podes usar Castle Windsor, si te preocupa mucho la eficiencia
> >> podes
> >> >> > usar PostSharp
> >> >> > etc etc? Aprender lenguajes dinamicos, ver porque los que escriben en
> >> >> > algunos de ellos se rien de MVP, MVC e incluso de IoC :)
> >> >> > Gustavo.
>

> >> >> > 2010/4/5 Edgar Ramos <eramose...@gmail.com>

> >> >> >> altnet-hispan...@googlegroups.com<altnet-hispano%2Bunsubscribe@go oglegroups.com>

> >> >> >> Para tener acceso a más opciones, visita el grupo en
> >> >> >>http://groups.google.com/group/altnet-hispano?hl=es.
>
> >> >> > --
> >> >> > Has recibido este mensaje porque estás suscrito al grupo
> >> >> > "AltNet-Hispano" de
> >> >> > Grupos de Google.
> >> >> > Para publicar una entrada en este grupo, envía un correo electrónico
> >> a
> >> >> > altnet-...@googlegroups.com.
> >> >> > Para anular tu suscripción a este grupo, envía un correo electrónico
> >> a

> >> >> > altnet-hispan...@googlegroups.com<altnet-hispano%2Bunsubscribe@go oglegroups.com>

> >> >> > Para tener acceso a más opciones, visita el grupo en
> >> >> >http://groups.google.com/group/altnet-hispano?hl=es.
>
> >> >> --
> >> >> Has recibido este mensaje porque estás suscrito al grupo
> >> "AltNet-Hispano"
> >> >> de Grupos de Google.
> >> >> Para publicar una entrada en este grupo, envía un correo electrónico a
> >> >> altnet-...@googlegroups.com.
> >> >> Para anular tu suscripción a este grupo, envía un correo electrónico a

> >> >> altnet-hispan...@googlegroups.com<altnet-hispano%2Bunsubscribe@go oglegroups.com>

> >> >> Para tener acceso a más opciones, visita el grupo en
> >> >>http://groups.google.com/group/altnet-hispano?hl=es.
>
> >> > --
> >> > Has recibido este mensaje porque estás suscrito al grupo
> >> "AltNet-Hispano" de
> >> > Grupos de Google.
> >> > Para publicar una entrada en este grupo, envía un correo electrónico a
> >> > altnet-...@googlegroups.com.
> >> > Para anular tu suscripción a este grupo, envía un correo electrónico a

> >> > altnet-hispan...@googlegroups.com<altnet-hispano%2Bunsubscribe@go oglegroups.com>

> >> > Para tener acceso a más opciones, visita el grupo en
> >> >http://groups.google.com/group/altnet-hispano?hl=es.
>
> >> --
> >> Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano"
> >> de Grupos de Google.
> >> Para publicar una entrada en este grupo, envía un correo electrónico a
> >> altnet-...@googlegroups.com.
> >> Para anular tu suscripción a este grupo, envía un correo electrónico a

> >> altnet-hispan...@googlegroups.com<altnet-hispano%2Bunsubscribe@go oglegroups.com>

> >> Para tener acceso a más opciones, visita el grupo en
> >>http://groups.google.com/group/altnet-hispano?hl=es.
>
> >  --
> > Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano"
> > de Grupos de Google.
> > Para publicar una entrada en este grupo, envía un correo electrónico a
> > altnet-...@googlegroups.com.
> > Para anular tu suscripción a este grupo, envía un correo electrónico a

> > altnet-hispan...@googlegroups.com<altnet-hispano%2Bunsubscribe@go oglegroups.com>

[Diego Mijelshon]

:s/tu server-side API/MI server-side api/

El análisis de kzu es bueno, siempre que dejes esa generalización de lado ;-)

   Diego

2010/4/9 listas q <qlis...@gmail.com>

[Daniel Cazzulino]

> porq hoy en dia el 90% de los consumidores de tu server-side API son clientes rest (AJAX con JSON o Atom)

se podrá conseguir algo de info respaldando esto ?

si queres q tu API sea consumida por vos y otros tambien, claro. Hay muy pocos ejemplos de plataformas q expongan APIs SOAP-only ya, y REST es una movida (si bien no novedosa ni mucho menos) q por fin esta siendo mainstream. REST te asegura q muchos de los beneficios de la "web" apliquen a tus servicios.

 

> porq con MVC tenes q crear exactamente lo mismo para cada entidad q tenes (si queres consistencia rest-like)

no tengo idea de ASP.NET MVC, pero si es exactamente lo mismo entonces
no sería fácil generar esto automáticamente ? rails por nombrar un
framework MVC es REST automáticamente...cada entidad que creas ya es
REST, me imagino que en ASP.NET si no lo ponen en alguna versión
futura se podrá generar facilmente, o no ?

soporte para querying cross-entities, con linking, inline expansion y projections es bastante dificil de "auto generar" a menos q tengas un modelo atras (i.e. EF u alguna otra cosa) q te permita armar la capa de querying. No tengo idea de como expondrias eso en endpoints MVC, pero seguramente no es algo trivial ni mucho menos.

todo eso lo tenes gratis ya con Astoria/WCF Data Services.

 

> para "green field", yo creo q ni lo pensaria demasiado... el cliente siempre va a querer "algo de AJAX, como GMail y Google Reader, viste?" ;)

Entiendo que si lo que quiere es "algo de AJAX" entonces no necesito
que sea todo REST, ni siquiera todo JSON, en todo caso podría
agregarlo para las entidades que lo necesito o quizás ni siquiera eso
dependiendo de los requerimientos que tenga ?

ajap, podes exponer solo lo q queres via Astoria.

 

> EF + WCF Data Services + Silverlight/AJAX

tampoco tengo ni idea de Silverlight, pero no sufre de los mismos
problemas que Flash ? No es SEO friendly, no tiene deep linkink, no
tiene accesibilidad (WAI, section 508), etc.

un google search por silverlight seo te devuelve bastante info. hay formas de hacer q sea mucho mas SEO friendly.

ni idea de WAI, pero silverlight soporta deep linking y browser history navigation, tengo entendido (otro search por "silverlight deep linking" tb tira bastante info)

 

(pero a diferencia de Flash no tiene encima la contra de que está
instalado en un porcentaje muy pequeño de computadoras ?)

50%+ solo para Silverlight (no contando Moonlight en Linux) esta lejos de ser pequenio creo.

http://www.riastats.com/#

(es maso el numero q tiro tb ScottGu recientemente.

[listas q]

Gracias Daniel por tu respuesta !

Quique