DAL "Typed DataSets" o Custom Business Object

Question

Deseo recibir sus opiniones sobre las prácticas recomendadas de "DataSet Designer" y DAL (Data Access Layer). Uso Visual Studio 2010 Framework .NEt 4.0.

Para mi entendimiento "diseñador conjunto de datos" me permiten crear automáticamente estrictamente mecanografiados a DataSet con DataTable y el adaptador, éste consistirá en DAL directamente en Visual Studio 2010.

me gustaría saber: - Si en bienes escenario "DataSet Designer" está funcionando bien, o es mejor escribir Custom Business Object. - Si existe otra solución nueva introducida en .net 4.0

¡Gracias por su apoyo! :-)

Answer 1

Personalmente prefiero los objetos comerciales personalizados con su flexibilidad, pero es más trabajo. También consulte con Entity Framework y Linq To Sql. Entity Fx tiene mucha más flexibilidad en .NET 4.0. Este article debería comenzar con Entity Fx.

Answer 2

Sugeriría un ORM como Entity Framework o Nhibernate.

Conjuntos de datos huele demasiado a la forma de pensar de la base de datos y personalmente tuve muchos problemas para trabajar con ellos. Simplemente se rompen con bastante frecuencia y arrojan errores extraños que son difíciles de solucionar.

Algunas otras preguntas relacionadas que puede resultar interesante

What are the advantages of using an ORM?

ASP.NET DataSet vs Business Objects/ORM

Answer 3

Uso ADO.NET Entity Framework, que es donde va el futuro de ORM de Microsoft. O bien, considere uno de código abierto como NHibernate ...

HTH.

Answer 4

En todo caso creo que deberías mirar en EntityFramework. Hay arelots de great tutoriales disponibles para que comiences.

Answer 5

Con el advenimiento del framework .Net 4.0 y la introducción de LINQ to SQL, he estado adoptando un DAL personalizado de objetos comerciales estrictamente escritos. Experimentamos con Entity Framework brevemente, pero al final llegamos a la conclusión de que es muy similar a DataSets en que el código generado automáticamente, aunque práctico, está demasiado lleno de basura adicional que finalmente no usamos.

Hemos encontrado que escribiendo LINQ en nuestro DAL y extrayendo datos en nuestras clases personalizadas, podemos optimizar nuestro acceso a los datos y controlar el uso de los datos de manera funcional. Ha sido un proceso muy útil, pero les ha costado un poco a los desarrolladores junior aferrarse a él.

Answer 6

NHibernate. Especialmente si estás usando Oracle.

Answer 7

Personalmente estoy de acuerdo con Joel Etherton, condicionalmente.

Si tiene un proyecto lo suficientemente pequeño que incluso con la hinchazón de EF todavía no está mirando demasiado el código de shenanigan, diría que la conveniencia que ofrece vale la pena. Sin embargo, en las bases de código más grandes, puede ser mucho para ablandar tanto la hinchazón.

El otro beneficio para EF frente a los objetos comerciales de estilo antiguo que no se menciona, es con la implementación de EF que probablemente obtendrá actualizaciones más sencillas a versiones .NET nuevas aprovechando los beneficios en el próximo .NET sin tener que reescribir un montón de código a mano. (Esto también puede ser un arma de doble filo, ya que actualizar a .NET nuevo con EF puede afectar el comportamiento de tu dal, en comparación con un dal escrito a mano es menos probable que se vea afectado).

Dicho esto, de acuerdo con Joel Etherton, escriba el dal más pequeño y simple que pueda implementar LINQ, el dal siempre es demasiado importante para hacer excesivamente complejo cada vez que se puede evitar.

Answer 8

Tengo que trabajar con conjuntos de datos tipados y es una pesadilla. Si tienes una opción, nunca la uses. Todo es mejor.

Answer 9

Si no quiere perder el tiempo, no aprenda DataSets. Estudie los conceptos generales del mapeo relacional de objetos, sus pros y sus contras. Mire proyectos como Hibernate para Java o Doctrine para PHP. Se terminaron los enfoques detrás de DataTables y DataSets que proporcionan solo el ajuste de los objetos de la base de datos. Su marco debe guiarlo para diseñar su modelo de dominio, no el esquema de la base de datos.

Answer 10

En mi compañía, hemos estado usando Typed DataSets por un tiempo, y hemos tenido una experiencia generalmente positiva. Entiendo que muchas personas no les gusta conjuntos de datos, y hay herramientas de acceso a los datos más recientes, sin duda por ahí, pero ya que lo preguntas sobre un escenario del mundo real, aquí están algunos de mis requerimientos y conclusiones:

• necesidad de ser capaz de leer SQL Server, MS Access y fuentes de datos FoxPro
acceso
• SQL Server es sólo a través de las llamadas sproc (no es mi elección)
• relativamente fácil de aprender, especialmente para los desarrolladores nuevos a ASP.NET

He explorado personalmente el acceso de bajo nivel de ado.net, conjuntos de datos tipados, linq-to-sql, y simplemente escribiendo clases personalizadas de acceso a datos. Aún no he examinado el Entity Framework, ya que la versión incluida en VS2008 parecía tener algunas críticas mixtas, y no tuve acceso a VS2010 hasta hace poco (todavía tengo previsto revisar EF en algún momento de este año).

Elegimos utilizar Typed DataSets porque parecían ofrecer un desarrollo más rápido contra SPROCS y encontramos un tutorial muy completo de Scott Mitchell en el sitio asp.net: http://www.asp.net/data-access/tutorials.

En cuanto a nuestra experiencia hasta ahora, ha sido buena en su mayoría. El diseñador de DataSet genera una gran cantidad de código incluso para un pequeño número de tablas (< 20). Hacer cambios en los SPROCS ha causado algunos dolores de cabeza, pero me gustaría que se me muestre una herramienta que lo haría más fácil.

Una cosa que podría tratar de tomar una decisión más fácil: crear un pequeño problema de dominio como una página de edición de clientes o una página de entrada de pedidos, e implementarlo varias veces usando una variedad de tecnologías. Lleva algo de tiempo hacerlo, pero es una buena forma de aprender y puede comparar las tecnologías por usted mismo. Hicimos esto y pareció ayudar mucho.