#7167 espero que no estes insinuando que mongodb no es la eleccion correcta para la aplicacion de mi panaderia con 4 entidades
#7170 Entonces si que tienen que tener cosas buenas los frameworks de PHP para decidir usarlos... Te pongo mi ejemplo, a mi CoreData o Alamofire me pueden solucionar la vida en conexiones a bbdd o a red, pero es mi trabajo hacer que el código de mi aplicación no dependa de esos Frameworks si no que sea a la inversa.
Así si el día de mañana tengo que cambiar cualquiera de ellos lo único que tengo que modificar son mis datasources.
Si este concepto no es trasladable al mundo web, me parece una putada.
#7172 Curioso que no sepas cómo rulan estas cosas siendo programador. Normalmente se suele tener una idea general del mundillo pero tú, en cambio, estás totalmente polarizado. Me resulta curioso, no es un ataque (por si las moscas).
Es que el propio framework al completo es el mecanismo de inversión de dependencias... te dice 'tu pon esto así y así y en este sitio y yo me encargo de que funcione'
#7173 Para nada lo he sentido como un ataque jajaja me gustan estas conversaciones 
He sido totalmente autodidacta a la hora de aprender a programar y he consumido muchísimo material de la gente que es experta en la materia y algo bueno(o malo) que tengo es, que antes de hacer cualquier cosa, me intento informar de las buenas prácticas y de la tecnología que uso. El mundo web (JS,php, etc) lo intenté tocar en su día pero no me llamó nada de nada, sin embargo, con Android y Swift me motiva bastante aprender a hacer las cosas bien y marcar la diferencia con el típico programador estándar. Cualquiera puede hacer una aplicación móvil hoy en día, pero hacerla bien es otra historia. También imagino que influye que estoy acostumbrado a trabajar por libre, por lo que si tengo que hacer alguna ñapa, el que se la come luego soy yo, por lo que no es plan jaja
También es gracioso que me resultó mucho más sencillo abstraerme del framework de Apple que del de Android, cosa que no me esperaba en absoluto cuando empecé en este mundillo.
#7172 es imposible no acoplarse a un ORM, salvo que hagas un proxy sobre el ORM lo cual es absurdo porque ya lo es el ORM en sí.
Sobre el Alamofire o cualquier rest-client, si, lo habitual es colocar un adaptador encima de cualquier librería/gema/pod para abstraer la funcionalidad del sistema, ya sabes, cosas de acoplamientos y tal.. el solid ese del que tanto gusta hablar por aquí..
Y como aporte un poco hater diré que cualquier cosa que pienses que en "mobile lo hacemos así, que putada si en web no", que en web os sacamos como 10 años de desarrollo, vosotros solo consumís recursos, nosotros los generamos 
También es gracioso que me resultó mucho más sencillo abstraerme del framework de Apple que del de Android
Vale, creo que ya veo por donde van los tiros de tu confusión... Android e IOS no son frameworks, o al menos lo que lo que la gente suele entender por un framework. El equivalente a usar un framework para móviles sería usar ionic, cordova o algún invento de esos
#7176 Un cliente rest y un orm a fin de cuentas son lo mismo que son proveedores de datos. Por qué un cliente rest puede tener un proxy y un orm no?
si mañana queremos cambiar el orm, también vas a cambiar toda la capa de datos? mejor cambiar solo la parte que te acopla al orm.
#7178 porque el protocolo http es algo mucho mas simple que lanzar consultas a una base de datos, pero vaya, que el ORM lo que busca es precisamente lo que dices, ser transparente entre el sistema y la bdd, la idea es que sin importar que tipo de base de datos SQL (o NoSQL), solo con cambiar el adaptador del ORM, debería casi funcionarte outofthebox, si tienes que pasar de SQL a NoSQL, el problema no es de la abstracción del ORM, es de tu analisis y resolución del problema que tienes.
cargar (descargar) un json de unos 5MB desde un server con unos 10-15k registros y parsearlos en JS no es muy loco, no?
(he dicho JS, lo sé xd)
#7177 La frase la verdad que no es muy acertada. Debería haber dicho "abstraerme de los Framework de iOS y los de Android". Cuando estás bastante metido en mi mundillo y te mueves por charlas de gente importante te das cuenta como el 99% de los ejemplos que te pone Android o Apple en su documentacion para hacer cualquier cosa te incitan a depender de ellos, siempre hay una manera alternativa para hacer correctamente las cosas. Para que te hagas una idea: Objective C, Swift o Java son lenguajes, las herramientas que te proporciona Apple o Android para hacer las cosas mas sencillas con esos lenguajes, son dependencias que debes evitar.
#7177 Desconozco si has programado mucho para móviles, pero lo habitual en Android por ejemplo es usar Retrofit + AsyncTask en las llamadas de red y eso es un error garrafal desde el punto de vista de los principios SOLID y una buena arquitectura. Y sin ánimo de ofender, no somos pintaAPIs xD
#7184 no tiene nada que ver con lo qué te he plateando. Por qué haces abstracción en un cliente rest y no la haces o lo ves absurdo en un ORM.
El propio ORM es una abstracción correcto pero no dejas de tener dependencia con el ORM.
#7185 pues claro, al igual que tendrás dependencia del adaptador que crees para tu rest-client, por cojones alguien tiene que tener acomplamiento con alguien.
Tu solución se llama.. sobreingeniería, lo que haces es que si en el hipotético, extraño y mas que improbable caso de que tengas que cambiar de SQL a NoSQL en algún punto del proyecto, reescribiendo tu adaptador crees que no se resentirá tu sistema pero lo único que haces es limitar la funcionalidad de un ORM tras una capa sin apenas funcionalidad comparada con la que te ofrece el ORM. Estas creando un cuello de botella por un problema inexistente.
Una de las primeras cosas que aprendí en la informática fue: "no intentes apagar fuegos que ni aún arden ni puede que nunca ardan".
#7186 pues fíjate que si eres buen programador con experiencia igual sabes que algunos de esos fuegos sí que se van a encender.
#7187 lo que digo es que hagas un sistema abierto y escalable para el dia que tengas que ampliar funcionalidades del sistema lo hagas sin tener que pegarte un tiro, pero eso no tiene nada que ver con montarte paranoias de cosas mas que poco probables que alguna vez te ocurran.
#7190 200K, reinviertes y mejoras, hasta que puedas vender otro 5% por 10kk, y a retirarte con tu 90% y tus 10.2kk
#7168 La inversion de control es basicamente crear un contenedor para manejar la inyeccion sin tener que preocuparte de especificar la clase que quieres inyectar.
Un IoC no se entiende si no usas inyeccion de dependencias, no son dos cosas separadas
#7195 ¿Para que saquen un soft que permita ejecutar mi proyecto sin pagarme un duro mientras ellos se forran? Ofc ni un pavo les daba.
#7196 Espero que al menos tengas la decencia de comprarte el Zelda original. Aunque supongo que tampoco.
#7197 Cierto, voy a hacer un producto que sirva a ver a ver... ¡Para aprovecharme del producto de otros sin tener que pagarlo! Y además, voy a poner que si me pagas a mí, puedes aprovecharte del producto de otro 1 semana antes que el resto. Y espérate, ¡aun hay más! Como cada día 1 del mes se reinicia la gente que me paga, voy a esperarme a sacar mi producto para robar el producto de otros el día 2! Así los que ya me han pagado me tienen que volver a pagar! hohoho ¡Soy un genio de los negocios!
#7197 Hombre pues claro, me he comprado un juego a 60€ para una plataforma que no tengo, solo para esperar a que saquen un emulador que lo mueva como se merece, no sé como dudas si quiera.
