Pregunta

Actualmente estoy usando NetTiers para generar mi capa de acceso a datos y la capa de servicio.He estado usando NetTiers por más de 2 años y la he encontrado muy útil.En algún punto tengo que mirar LINQ así que mis preguntas son...

  1. Ha alguien más pasado de NetTiers de LINQ to SQL?
  2. Fue este conmutador a través de una buena o mala cosa?
  3. ¿Hay algo que yo deba conocer?
  4. Te recomiendo este cambio?

Básicamente me daría la bienvenida a cualquier idea .

¿Fue útil?

Solución

  1. No
  2. Ver #1
  3. Usted debe tener cuidado de estándar de abstracción de la sobrecarga.También es muy SQL Server basado en su estado actual.
  4. Usted está utilizando SQL Server, entonces tal vez.Si usted está usando LINQ para otras cosas ahora como más datos XML (grande), datos de Objetos, conjuntos de datos, entonces sí se podría cambiar para tener un uniforme de sintaxis de los datos de todos ellos.Como lagerdalek mencionó si no está roto, no lo arregles.A partir de la mirada rápida en .netTiers Marco de Aplicación, yo diría que si usted ya tiene una inversión con la que la solución parece darle mucho más que una simple Capa de Acceso a Datos y usted debe seguir con ella.

Desde mi experiencia LINQ to SQL es una buena solución para los pequeños y medianos proyectos.Es un ORM que es una gran manera de aumentar la productividad.También debe darle otra capa de abstracción que permite cambiar la capa de debajo para algo más.El diseñador de Visual Studio (y I belive VS Express también) es muy fácil y sencillo de usar.Se le da el común de arrastrar-soltar y basados en las propiedades de la edición de las asignaciones de objeto.

@ Jason Jackson - El Diseñador le permite agregar propiedades a mano, sin embargo es necesario especificar los atributos de la propiedad, pero de hacerlo una vez, puede tardar 3 minutos más que el inicial arrastrando de la tabla en el diseñador, sin embargo, sólo es necesario una vez por el cambio en la base de datos.Esto no es muy diferente de otros Orm, sin embargo, usted está en lo correcto que se puede hacer esto mucho más fácil, y encontrar sólo aquellas propiedades que han cambiado, o incluso implementar algún tipo de herramienta de refactorización para tales necesidades.

Recursos:

Tenga en cuenta que En paralelo LINQ está siendo desarrollado para permitir un rendimiento mucho mayor en los equipos multinúcleo.

Otros consejos

Traté de usar Linq to SQL en un proyecto pequeño, pensando que yo quería algo que podría generar rápidamente.Me encontré con un montón de problemas en el diseñador.Por ejemplo, en cualquier momento que usted necesita para agregar una columna a una tabla que, básicamente, tienen que quitar y volver a agregar la definición de la tabla en el diseñador.Si usted tiene cualquier conjunto de propiedades en la tabla a continuación, usted tiene que volver a configurar las propiedades.Para mí esto realmente ralentizado el proceso de desarrollo.

LINQ to SQL en sí es agradable.Me gusta mucho la extensibilidad.Si se puede mejorar el diseñador yo podría intentarlo de nuevo.Creo que el marco se beneficiaría de un poco más de funcionalidad dirigida a una modelo desconectada como el desarrollo web.

Echa un vistazo Scott Guthrie LINQ a SQL serie las entradas del blog para algunos grandes ejemplos de cómo usarlo.

NetTiers es muy bueno para generar un pesado y robusto DAL, y la utilizamos internamente para las principales librerías y frameworks.

Como yo lo veo, LINQ (en todas sus encarnaciones, pero específicamente en lo que creo que estás preguntando a SQL) es fantástico para el acceso rápido a los datos, y por lo general lo uso para el más ágil de los casos.

Ambas tecnologías son muy poco flexibles a cambios sin regeneración del código o dbml capa.

Dicho esto, se utiliza correctamente LINQ 2 de SQL es una solución robusta, y que incluso podría empezar a usarlo para el desarrollo futuro debido a su facilidad de uso, pero yo no lo tire a la basura su actual DAL para que - si no se rompió ...

Mi experiencia me dice que utilizando linq, puede hacer las cosas más rápido, sin embargo, la actual acciones a la base de datos son más lentos.

Así que...si usted tiene una pequeña base de datos, voy a decir que ir a por ella.Si no, me gustaría esperar para algunas mejoras antes de cambiar

Estoy usando LINQ to SQL en bastante grande proyecto ahora mismo (alrededor de 150 tablas) y se está trabajando muy bien para mí.La última ORM que usé fue IBatis y funcionó bien, pero tomó un montón de trabajo de campo para obtener sus asignaciones de hecho.LINQ to SQL funciona muy bien para mí y hasta ahora ha demostrado ser muy fácil de usar fuera de la caja.Hay definitivamente algunas diferencias que tienen que superar en la transición, pero yo recomendaría el uso de la misma.

Nota de lado, nunca he usado o leer acerca de NetTiers así que no voy a descuento de su efectividad, pero LINQ to SQL, en general, ha demostrado ser un muy viable ORM.

Nuestro equipo se utiliza para uso NetTiers y encontrado para ser útil.PERO...el más usado, el más encontramos los dolores de cabeza y dolor de puntos con ella.Por ejemplo, cada vez que se haga un cambio a la base de datos, deberá volver a generar el DAL con CodeSmith que participan:

  • re-generación de miles de líneas de código en 3 proyectos independientes
  • re-generación de cientos de procedimientos almacenados

Tal vez hay otras formas de hacerlo, pero esto es lo que tenía que hacer.La re-generación del código fuente estaba bien, de miedo, pero está bien.El verdadero problema llegó con los procedimientos almacenados.No limpia sin usar procedimientos almacenados de modo que si se quita una tabla a partir de su esquema y re-gened su DAL, los procedimientos almacenados para que la tabla no se eliminan.También, este se convirtió en un dolor de cabeza para la base de datos de secuencias de comandos de cambio en la que tenía que comparar la antigua estructura de base de datos a la nueva y crear un script de cambios de la actualización de las instalaciones de cliente.Esta secuencia de comandos puede ejecutar a decenas de miles de líneas de código sql y si hay un problema de ejecución, que invariablemente era, era todo un dolor de resolverlo.

Entonces la luz se encendió, NHibernate como un ORM.Ciertamente tiene un tiempo de rampa a él, pero es bien vale la pena.Hay un montón de apoyo para él, así que si hay algo que usted necesita hacer, es más que probable que se ha hecho antes.Es muy flexible y le permite controlar cada aspecto de ella y, a continuación, algunos.También es cada vez más fácil y más fácil de usar.Habla Nhibernate es ascendente y que viene como una gran manera de deshacerse de la asignación xml de los archivos necesarios y NHibernate Analizador proporciona una excelente interfaz para ver lo que está pasando detrás de las escenas para aumentar la eficiencia y eliminar la redundancia.

Movimiento de NetTiers de NHibernate ha sido doloroso, pero en una buena forma.Esto nos ha obligado a moverse en una mejor arquitectura y re-evaluar las necesidades funcionales.NetTiers siempre toneladas de código de acceso a datos, obtener esta entidad por su id, obtener esta otra entidad por su clave externa, obtener un tlist y vlist de esto y de aquello, pero fue innecesario y sin usar.NHibernate con un genérico y el repositorio de repositorios personalizados sólo cuando se necesita reducción de toneladas de código no utilizado y realmente el aumento de la legibilidad y la fiabilidad.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top