.net - ¿Cuál es el mejor paradigma de acceso a datos para la escalabilidad?
asp.net linq (9)
Creo que ADO.Net Data Services (antes llamado Astoria) tiene un papel muy importante que jugar. Encaja muy bien con la arquitectura de estilo REST de la web.
Dado que la web es escalable, supongo que todo lo que sigue a su arquitectura es escalable también. También es posible que desee vigilar los servicios de datos de SQL Server.
Hay tantas opciones diferentes que salen de microsoft para el acceso a datos. ¿Cuál es el mejor para aplicaciones escalables?
Linq
¿Deberíamos estar usando Linq? Ciertamente parece fácil, pero si conoces tu SQL realmente ayuda. También escuché que no puedes ejecutar consultas Async en ASP.NET usando Linq. Por lo tanto, me pregunto si es realmente escalable. ¿Hay sitios realmente grandes que usen Linq (con la posible excepción de stackoverflow)?
Marco de la entidad
No escuchas tanto razzmatazz sobre Entity Framework. Parece más cercano al modelo de Objetos con el que estoy familiarizado.
Astoria / Datos dinámicos
¿Deberíamos exponer nuestros datos como un servicio?
Estoy bastante confundido y eso es antes de entrar en los otros productos de ORM como NHibernate. ¿Alguna idea o sabiduría sobre cuál es mejor?
En estos días, el bloqueo de los procedimientos almacenados parece ser una forma de pensar en decadencia, al menos esas han sido mis observaciones actuales. Esa forma de pensar se presta al mundo de ORM ya que suelen ser más afectivos yendo en contra de las tablas directamente, pero cualquier ORM que valga la pena también permitirá el uso de procs, en algún momento no tendrá otra opción.
Hay muchas opiniones en torno a EF y, independientemente de lo que digan, bueno o malo, es un producto V1 y con la regla general de que MS tarda aproximadamente 3 revoluciones para hacerlo bien, puede ser prudente esperar la próxima revolución en menos.
Parece que el jugador más grande que hay en este espacio es NHibernate y hay mucho apoyo para esto en la comunidad. Linq, la función de idioma, no debería estar demasiado lejos para llegar a la pila de NHibernate.
Esta publicación es de 2008 antes de que la nube realmente despegara. Parece que se requiere una actualización de la respuesta. Proporcionaré algunos enlaces y una descripción general. Estoy seguro de que hay más publicaciones actualizadas en este sitio sobre este tema, y si las encuentro, agregaré los enlaces aquí.
Cuando se trata de la escalabilidad de los datos y la escalabilidad del procesamiento de transacciones, en 2017 necesitamos hablar sobre los proveedores de servicios en la nube y la nube.
Creo que los tres principales proveedores de nube en estos días son:
Costo
Una de las ventajas de usar servicios en la nube es que no hay costos iniciales, ni tarifas de terminación, y usted paga solo por lo que usa. (Citando el artículo de 2016 del Sr.Alba " Una comparación lado a lado de AWS, Google Cloud y Azure ")
Usamos AWS nosotros mismos. Pagamos solo mientras tenemos máquinas virtuales instaladas y en ejecución, por lo que puede ser una forma económica de comenzar. Por lo general, los proveedores de servicios cobran por minuto o por hora, pero se garantiza que lo tendrán todo ese tiempo.
Una manera más barata de ir es el precio spot del mejor esfuerzo. El precio Spot representa el precio por encima del cual debe pujar para garantizar que se cumpla una sola solicitud Spot. Cuando el precio de oferta está por encima del precio Spot, Amazon EC2 lanza su instancia Spot, y cuando el precio Spot sube por encima de su precio de oferta, Amazon EC2 finaliza su instancia Spot. (Sin descaro citar la Guía del usuario de Amazon aquí )
Una comparación lado a lado de AWS, Google Cloud y Azure es un buen artículo haciendo una comparación lado a lado de estos tres proveedores de servicios disponibles aquí .
Para una visión más académica de los servicios en la nube, lea el documento de 2010 de Yu, Wang, Ren y Lou " Lograr un control de acceso a datos seguro, escalable y preciso en la computación en la nube " en los procedimientos de INFOCOM 2010 disponibles aquí , pero puede necesita ser un miembro de IEEE para obtener acceso a él. Si bien es algo anticuado, es excelente y puedes usarlo como punto de partida.
El escalado en la nube ha estado explotando, y hasta hace poco esa escalada se realizó al iniciar nuevas máquinas virtuales, lo que llevó segundos, pero con los contenedores se pueden generar nuevas instancias en milisegundos. Para obtener más información al respecto, consulte Contenedores Docker y Docker aquí .
Me disculpo por que esta respuesta sea solo un montón de enlaces para obtener más información, pero pensé que la respuesta a esta pregunta debería tener una actualización. Espero que esto inspire a alguien a proporcionar más detalles de primera mano. Si ya ha publicado alguna información relacionada, considere proporcionar enlaces a sus propias publicaciones. ¡Gracias!
Hemos estado experimentando con LINQ en un entorno agrupado y parece estar escalando bien en las máquinas individuales y en todo el clúster. De las 3 opciones que ha proporcionado, diría que LINQ es la mejor opción, aunque cada opción tiene un público objetivo ligeramente diferente, por lo que debe definir qué hará con los datos antes de decidir sobre el paradigma de acceso.
Recomendaría NHibernate o Entity Framework. Para sitios grandes, usaría ADO.NET Data Services. No haría nada grande con LINQ to SQL. Creo que podría terminar con algunos problemas de escala interesantes de 2 niveles en lugar de 3 niveles, y también tendrán problemas para refactorizar a medida que los aspectos físicos de la base de datos cambien y esos cambios se propaguen en todo el código. Solo un pensamiento.
Si está hablando de bases de datos relacionales, entonces mi voto es para encapsular todas sus operaciones de datos en procedimientos almacenados, independientemente de cómo acceda a ellos desde las otras capas.
Si deshabilita todo el acceso de lectura / escritura a la base de datos, excepto a través de procedimientos almacenados, puede ocultar su modelo de datos detrás de contratos bien definidos. El modelo de datos es libre de cambiar, solo para que los procedimientos almacenados sigan respetando sus entradas y salidas.
Esto le da a los DBA libertad total para ajustar su aplicación y hacerla escala. Esta es una tarea muy, muy difícil cuando SQL es generado por una herramienta fuera de la base de datos.
Sugeriría linq. Se adapta bien a nuestro sitio y es lo suficientemente simple de usar.
Usa lo que sea que funcione para ti. Todos estos son más fáciles de configurar si ya tiene una base de datos bastante normalizada (es decir, una buena definición de claves principales y claves externas). Sin embargo, si tiene datos que no se normalizan fácilmente, Entity Framework es más flexible que LINQ to SQL, pero requiere más trabajo configurarlo.
utiliza procedimientos almacenados con LINQ ... ¡pero no permitas que los sprocs se conviertan en una capa de acceso a datos!