.NET Opciones de persistencia de objetos

Question

Tengo una pregunta que simplemente no me parece que haya encontrado una respuesta satisfactoria, ya sea porque no he estado buscando en el lugar correcto.

Nuestro sistema se construyó originalmente con .NET 1.1 (sin embargo, todos los proyectos admiten ahora 3.5) y todas las entidades se mantienen en la base de datos utilizando procedimientos almacenados y un "SQLHelper" que tiene los métodos de tipo ExecuteReader, ExecutreNonQuery.

Así que lo que generalmente sucede es que vamos a tener nuestras entidades por ejemplo, usuario y clases, y vamos a tener otra clase llamada UserIO que persiste esos objetos a base de datos con métodos como:

static UserIO.SaveUser(User user) 

La razón de el archivo IO separada es mantener el IO separado de la entidad embargo, no es más satisfactoria para simplemente llamar ?:

User.Save() 

Tal vez me equivoque, pero simplemente no se siente bien tener estos " IO "archivos dispersos por todo el lugar. Así que estoy pensando en buscar otras opciones para la persistencia y me pregunto dónde sería el mejor lugar para comenzar. He utilizado conjuntos de datos en el pasado, pero tuve algunas experiencias mixtas, particularmente con su rendimiento. Sé que LINQ está por aquí ahora, pero escuché que en lugar de LINQ debería estar usando el Entity Framework de ADO.NET, pero luego alguien más me dijo que el Entity Framework no es del todo correcto y que debería esperar C# 4.0. Si ese es el caso y con C# 4.0 a la vuelta de la esquina debería continuar con mi enfoque de archivo "IO" y comenzar con Entity Framework cuando finalmente se lanza C# 4.0. ¿O tal vez hay una estructura de clase más elegante que podría usar, por ejemplo,? utilizando clases parciales?

Debo decir que no estoy buscando reemplazar por completo el acceso a los datos que ya existe, estoy más preocupado con las nuevas entidades que estoy creando.

Lo siento si esta pregunta es un poco general, sin embargo, no tengo mucha gente para rebotar este tipo de pensamiento.

Answer 1

He utilizado con éxito Entity Framework 3.5. Hay algunos, que describiría como puristas, que sentían que el Marco de la Entidad violó algunas reglas y no deberían ser utilizados.

En mi opinión, las únicas reglas que importan son las suyas. Te recomiendo que comiences a experimentar con Entity Framework 3.5, ya que lo tienes ahora. Además, tan pronto como sea posible, usted (y casi todos los demás) deben comenzar a experimentar con .NET 4.0. El Release Candidate está disponible de forma gratuita, por lo que no hay ninguna razón para no saber al menos qué hay disponible.

Es posible que le parezcan los cambios de EF en 4.0 tanto que querrá esperar. Es tan probable que no sienta la necesidad de esperar, y pueda seguir adelante y beneficiarse de EF tal como está en 3.5. Lo hice, y estoy muy contento de no haber esperado.

Answer 2

Es un patrón común tener un repositorio que está separado del modelo. El nombre IO es único para dicho patrón, pero es válido. Ahora, dependiendo de con quién hables (las mentes de TDD te vienen a la mente), es posible que te falte el uso de una clase estática.

Answer 3

Si usted está buscando para los modelos de mapeo objeto-relacional se puede mirar en:

• NHibernate
• LLBLGen
• iBATIS

También hay una lista más larga aquí: http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET

En cuanto a la pregunta general de cómo diseñar un modelo de objeto para persistencia, gran parte de la elección del diseño depende de la complejidad del sistema, la extensibilidad que necesita, si necesita soportar almacenes de persistencia múltiples (SQLServer, Oracle , sistema de archivos, etc.), y así sucesivamente. El patrón que describes se ve como DataTansferObject (DTO). Es un diseño común para separar la lógica de persistencia de la lógica comercial.

Como un aparte, un principio general de un buen diseño de sistema es el single responsibility principle. Al construir un sistema, debe decidir si tiene sentido combinar diferentes responsabilidades en una sola clase. La combinación de responsabilidades a menudo puede complicar un sistema y crear conflictos de diseño que son difíciles de resolver.

Answer 4

Tener un conjunto de clases que implementen las funciones de datos a menudo se denomina programación escalonada. (http://en.wikipedia.org/wiki/N-tier). Al separar las clases que acceden al nivel de datos, se crea un sistema que es mucho más fácil de mantener. Si fusionó esas funciones en las clases que implementan las reglas comerciales en su aplicación, perdería muchas de las ventajas de tener un diseño de varios niveles.

Tener las funciones de acceso a datos escupir en sus propias clases es bueno (3 aplausos para el diseñador), sin embargo, tenerlas dispersas por todos lados es malo. Lo ideal sería que la fuente para esas funciones no estuviera en el mismo directorio o archivo (dependiendo del tamaño del proyecto). Si están todos juntos, obtienes muchas ventajas. Tenerlos divididos en (al azar) muchas ubicaciones derrota el propósito de modularizar este código.

Answer 5

Un patrón que utilizo bastante regularmente es: Cada objeto tiene la siguiente:

• objeto de transferencia de datos (DTO) - Esto mantiene la memoria utilizada por los conjuntos de datos lo más pequeño posible.
• Business Object - Eso lleva al menos lo anterior DTO como constructor - Esto realiza función alguna en el DTO que no es una función ABM
• ABM/métodos Persistentes en una clase repositorio

Este último se puede hacer de 2 maneras. Puede tener una gran clase de repositorio, lo cual está bien para aplicaciones/componentes con solo unos pocos objetos, o puede tener repositorios separados para cada objeto.

Echa un vistazo al blog de Rudy Lacovaras. Recientemente realizó una serie de publicaciones sobre acceso eficiente a datos utilizando un patrón similar.