¿Qué problema está tratando de resolver Microsoft con todas estas estrategias de acceso a datos?

Question

Parece que hay muchas estrategias diferentes de acceso a datos que salen de Microsoft. Hay ADO.NET 'clásico', Linq2Sql, ADO.NET Entity Framework, ADO.NET Data Services, ADO.NET Dynamic Data. Estoy seguro de que me he perdido algo. Para mí, parece que hay mucha confusión en torno a dónde cada marco se ajusta a la arquitectura de una aplicación. ¿Qué problema está tratando de resolver Microsoft con todos estos métodos de acceso a datos?

Answer 1

Están tratando de resolver el problema de cómo aumentar las ventas y la cuota de mercado. Con ese fin, varios grupos dentro de Microsoft intentan atacar el problema de cómo conseguir que más desarrolladores y usuarios finales usen sus productos. Diferentes grupos presentan diferentes tecnologías y, como cualquier empresa grande, Microsoft se esfuerza por mantener sus tecnologías alineadas y grupos trabajando para el mismo fin. Además, a medida que aparezcan las tecnologías más nuevas, necesitan mantener (o mejor aún, establecer) el ritmo y seguir respaldando las tecnologías más antiguas en las que sus clientes han invertido. El resultado final para cualquier tipo de empresa razonablemente grande, incluido Microsoft, es una selección un tanto embrollada de selecciones de tecnología.

Answer 2

Tu confusión es nuestra frustración. Muchos de los que tomamos estas decisiones arquitectónicas para nuestros sitios web hemos levantado la mano con la falta de claridad de Microsoft y las buenas prácticas de desarrollo en este tema.

Mi equipo ciertamente se quemó por Linq2Sql.

Ahora construimos nuestro sitio web con un enfoque de Diseño Dirigido por Dominio y específicamente Arquitectura de Cebolla de Palermo (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/). Los objetos comerciales son solo POCO y no tienen dependencias en la infraestructura.

La infraestructura ahora está a cargo de NHibernate y un ORM personalizado para nuestro CMS. Los dolorosos costos de inicio de estos han sido superados por el conocimiento de que la comunidad continuará moviendo a NHibernate en la mejor dirección y controlaremos la fuente de nuestro ORM. Peor empeora y Microsoft lanza algo realmente convincente que funciona en una arquitectura DDD, solo necesitamos reescribir nuestra capa de infraestructura.

Answer 3

No veo el sentido de esta pregunta. De hecho, es un poco troll.

• ADO.NET es la tecnología de acceso a datos original de .NET 1.0. Claramente no pertenece a ninguna discusión sobre nuevas "estrategias de acceso a datos"
• LINQ to SQL es uno de los proveedores LINQ originales. Proporciona una asignación de uno a uno entre las estructuras de la base de datos y los tipos utilizados en un programa. Estaba destinado a trabajar con SQL Server
• ADO.NET Entity Framework es más flexible. Se suponía que funcionara con cualquier proveedor ADO.NET, y tiene una capa de mapeo, de modo que el programa funciona con clases que están más cerca de ser entidades comerciales que de tablas de bases de datos. Por ejemplo, una sola entidad puede incluir datos de múltiples tablas. Microsoft decidió dedicar más esfuerzo a EF que a LINQ to SQL.
• ADO.NET Data Services es una capa de servicios sobre EF. Si fuera a producir su propio servicio para no hacer más que exponer sus datos, entonces es una apuesta decente. Utiliza una interfaz REST y puede exponer los datos en formato ATOM.
• ASP.NET Los datos dinámicos no son una estrategia de acceso a datos. Ver http://www.asp.net/dynamicdata/.

Las distinciones son lo suficientemente claras como para que una cantidad trivial de investigación las haya aclarado.

Answer 4

Han tenido una estrategia de datos por edades. De hecho, puede y debe buscar "Estrategia de acceso a datos de Microsoft" y encontrará enlaces antiguos y nuevos (es decir, el año 1998 y su estrategia OLEDB).

Creo que lo que estás buscando es here del año 2007 que aunque tiene 2 años es sobre XML, ADO.NET, Datos, LINQ, SQL Server, Visual Studio Orcas, Entity Framework ... se dirigen a la pregunta ¿Microsoft tiene una estrategia de acceso a datos?:

Sí, resulta que sí. Microsoft visualiza una plataforma de datos de entidad que permite a los clientes definir un modelo de datos de entidad común en los servicios de datos y aplicaciones. La plataforma Entity Data es una visión de lanzamiento múltiple, con versiones futuras de herramientas de informe , replicación, definición de datos, seguridad , etc. todo se construye alrededor de un modelo de datos de entidad común. ...

Mike Pizzo, Arquitecto, datos programabilidad

espero que ayude.

Answer 5

Encuentro el artículo en http://msdn.microsoft.com/en-us/magazine/cc700331.aspx una buena introducción técnica a Entity Framework si no está familiarizado con los conceptos subyacentes.

Aquí es una sección que es relevante para esta pregunta explicando algunos de los objetivos y relación con ADO.Net de EF ...

El ADO.NET Entity Framework es una evolución de ADO.NET y la primera implementación concreta del EDM, proporcionando un mayor nivel de abstracción cuando se desarrolla en una base de datos relacional. En la versión 1.0, el equipo se ha centrado en construir las bases de una plataforma, más que un simple ORM, que permitirá a los desarrolladores trabajar contra un modelo conceptual o de objetos con un mapeo muy flexible y la capacidad de adaptarse a un alto grado de divergencia de la tienda subyacente.

Este alto grado de flexibilidad y divergencia de la tienda subyacente es la clave para permitir que la base de datos y las aplicaciones evolucionen por separado. Cuando se realiza un cambio en el esquema de la base de datos, la aplicación está aislada del cambio por Entity Framework, y a menudo no se requiere reescribir partes de la aplicación, sino simplemente actualizar los archivos de mapeo si es necesario para acomodar el cambio.

Para comenzar a desarrollar la plataforma ADO.NET, Entity Framework se basa en el modelo de proveedor ADO.NET 2.0 existente, y los proveedores existentes se actualizan ligeramente para admitir el nuevo Entity Framework y la funcionalidad ADO.NET 3.5. Elegimos implementar sobre el modelo de proveedor de ADO.NET existente para garantizar un modelo de proveedor que sea familiar para la comunidad de desarrollo.