Arquitectura de un negocio de objetos de base de datos la capa de acceso a

https://stackoverflow.com/questions/118955

02-07-2019
|

Pregunta

Por diversas razones, estamos escribiendo un nuevo negocio y objetos de almacenamiento de datos de la biblioteca.Uno de los requisitos de esta capa es separar la lógica de las reglas de negocio, y el real de almacenamiento de datos de la capa.

Es posible tener múltiples de almacenamiento de datos de las capas que implementar el acceso a la misma de objeto - por ejemplo, una de las principales "base de datos" de almacenamiento de datos de código fuente que implementa la mayoría de los objetos, y otro "ldap" fuente que implementa un objeto de Usuario.En este escenario, el Usuario puede, opcionalmente, provienen de un LDAP de origen, tal vez con una funcionalidad ligeramente diferente (por ejemplo, no es posible guardar/actualizar el objeto de Usuario), pero por lo demás es utilizado por la aplicación de la misma manera.Otro de almacenamiento de datos de tipo podría ser un servicio web, o una base de datos externa.

Hay dos maneras principales que estamos buscando en la ejecución de este, y a mí y a un compañero de trabajo no están de acuerdo en un nivel fundamental, que es la correcta.Me gustaría algunos consejos sobre cual es el mejor para usar.Voy a tratar de mantener mi descripciones de cada uno de los tan neutral como sea posible, ya que estoy buscando algo de objetivo los puntos de vista aquí.

Los objetos de negocio son la base de las clases, y de almacenamiento de datos de objetos que heredan de business objects.Código de cliente trata con datos de almacenamiento de objetos.

En este caso, el común de reglas de negocio son heredados por cada uno de los datos objeto de almacenamiento, y es el almacenamiento de los datos de los objetos que son utilizados directamente por el código de cliente.

Esto tiene la implicación de que el código de cliente determina que el almacenamiento de datos método a utilizar para un objeto dado, porque tiene que declarar explícitamente un ejemplo para el tipo de objeto.Código de cliente necesita explícitamente saber la información de conexión para datos de cada tipo de almacenamiento que se está usando.

Si un almacenamiento de datos de la capa implementa una funcionalidad diferente para un objeto dado, el código de cliente de forma explícita conoce en tiempo de compilación porque el objeto se ve diferente.Si el almacenamiento de datos método es cambiado, el código de cliente tiene que ser actualizada.
Objetos de negocio de encapsular los datos de almacenamiento de objetos.

En este caso, los objetos de negocio son utilizados directamente por el cliente de la aplicación.Aplicación cliente pasa a lo largo de la base de la información de conexión a la capa de negocio.La decisión acerca de que el almacenamiento de datos método de un objeto se utiliza es de negocios de código objeto.La información de conexión sería un fragmento de datos tomados de un archivo de configuración (aplicación cliente en realidad no sabe/atención acerca de los detalles de la misma), que puede ser de una sola cadena de conexión para una base de datos, o varios pedazos de cadenas de conexión para diversos tipos de almacenamiento de datos.Almacenamiento de datos adicionales tipos de conexión también se pueden leer desde otro lugar - por ejemplo, una tabla de configuración en una base de datos que especifica las direcciones Url a los distintos servicios de la web.

La ventaja aquí es que si un nuevo método de almacenamiento de datos se agrega a un objeto existente, una opción de configuración se puede establecer en tiempo de ejecución para determinar el método a utilizar, y es totalmente transparente para las aplicaciones del cliente.Aplicaciones de cliente no necesita ser modificado si el almacenamiento de datos método de un objeto dado cambios.
Negocios objetos de clases base de datos de origen de los objetos heredan de business objects.El código de cliente se ocupa, fundamentalmente, con clases base.

Esto es similar a la del primer método, pero el código de cliente declara las variables de la base de negocios tipos de objetos, y de la Carga()/Create()/etc métodos estáticos en los objetos de negocio devolver el origen de datos adecuado para cada tipo de objetos.

La arquitectura de esta solución es similar a la del primer método, pero la principal diferencia es la decisión acerca de cuál de almacenamiento de datos de objeto de uso por un determinado objeto de negocio es hecha por la capa de negocio, no el código de cliente.

Sé que hay ya existentes ORM bibliotecas que ofrecen algunos de esta funcionalidad, pero por favor descuento de los de ahora (existe la posibilidad de que un almacenamiento de datos de la capa se implementa con uno de estos ORM bibliotecas) - tenga en cuenta también estoy deliberadamente no decirle a usted lo que se utiliza el lenguaje aquí, que es inflexible.

Estoy buscando algunos consejos generales aquí sobre qué método es el mejor para usar (o siéntase libre de sugerir algo más), y por qué.

Solución

puedo sugerir otra alternativa, con posiblemente el mejor de la disociación:objetos de negocio uso los datos de los objetos, y los objetos de datos implementar el almacenamiento de objetos.Esto debería mantener las reglas de negocio en los objetos de negocio, pero sin ninguna dependencia de la fuente de almacenamiento o formato, mientras que permite a los objetos de datos para apoyar lo que las manipulaciones son necesarios, incluyendo un cambio en el almacenamiento de objetos dinámicamente (por ejemplo,en línea/fuera de línea de la manipulación)

esto cae en la segunda categoría anterior (objetos de negocio de encapsular los datos de almacenamiento de objetos), pero se separa de datos semántica de mecanismos de almacenamiento de más claramente

Otros consejos

Usted también puede tener una fachada para evitar que su cliente llama a la empresa directamente.También se crea común los puntos de entrada a su negocio.

Como se ha dicho, su negocio no debe ser expuesto a la nada, pero el DTO y de la Fachada.

Sí.Su cliente puede lidiar con DTOs.Es la manera ideal para pasar los datos a través de su aplicación.

Por lo general, prefiero el "negocio objeto encapsula datos de objeto/almacenamiento" mejor.Sin embargo, en el corto se puede encontrar un alto nivel de redundancia con los objetos de datos y los objetos de negocio que puede parecer no vale la pena.Esto es especialmente cierto si usted opta por un ORM como la base de la capa de acceso a datos (DAL).Pero, en el largo plazo es donde está la verdadera pagar es:aplicación del ciclo de vida.Como se ilustra, no es raro que los "datos" provenir de uno o más de los subsistemas de almacenamiento (no limitada a RDBMS), especialmente con el advenimiento de la computación en la nube, y como es frecuente el caso en los sistemas distribuidos.Por ejemplo, usted puede tener algunos de los datos que provienen de un servicio Restful, otro fragmento de objeto o de un RDBMS, otra a partir de un archivo XML, LDAP, y así sucesivamente.Con esta realización, esto implica la importancia de la muy buena la encapsulación de los datos de acceso de la empresa.Cuidar las dependencias que se exponga (DI) a través de la c-tores y propiedades, también.

Dicho esto, un enfoque que he estado considerando la idea es poner la "carne" de la arquitectura en un negocio controlador.El pensamiento de los contemporáneos de acceso a datos más como un recurso que el modo de pensar tradicional, entonces el controlador acepta en un URI o cualquier otra forma de metadatos que puede ser utilizado para saber qué recursos de datos que deben manejar los objetos de negocios.Entonces, el objeto de negocio de por sí NO encapsular el acceso a los datos;en lugar del controlador.Esto mantiene a los objetos de negocio ligero y específicos y permite que su controlador de proporcionar optimización, composability, transacción ambiente, y así sucesivamente.Tenga en cuenta que el controlador sería entonces el "host" de su objeto de negocio de las colecciones, como el controlador de la pieza de muchos Orm hacer.

Además, considere también la gestión de reglas de negocio.Si squint duro en su UML (o el modelo en su cabeza, al igual que yo :D ), usted notará que su negocio modelo de reglas son en realidad otro modelo, a veces incluso persistentes (si usted está usando un motor de reglas de negocio, por ejemplo).Me gustaría considerar la posibilidad de dejar el negocio de la controladora, de hecho, el control de las reglas del subsistema demasiado, y deje que su negocio objeto de referencia de las normas a través del controlador.La razón es porque, inevitablemente, la regla de las implementaciones menudo deben llevar a cabo las búsquedas y la verificación cruzada, con el fin de determinar la validez.A menudo, es posible que requiera tanto hidratado objeto de negocio de las búsquedas, así como back-end de base de datos de las búsquedas.Considere la posibilidad de la detección de las entidades duplicadas, por ejemplo, donde sólo el "nuevo" uno está hidratado.Dejando a sus reglas, a ser administrados por su negocio controlador, a continuación, puede hacer casi cualquier cosa que usted necesita sin sacrificar la que limpia y agradable, la abstracción en su "modelo de dominio."

En pseudo-código:

using(MyConcreteBusinessContext ctx = new MyConcreteBusinessContext("datares://model1?DataSource=myserver;Catalog=mydatabase;Trusted_Connection=True ruleres://someruleresource?type=StaticRules&handler=My.Org.Business.Model.RuleManager")) {

User user = ctx.GetUserById("SZE543");
user.IsLogonActive = false;
ctx.Save();
}

//a business object
class User : BusinessBase {
  public User(BusinessContext ctx) : base(ctx) {}

  public bool Validate() {
    IValidator v = ctx.GetValidator(this);
    return v.Validate();
  }
}

// a validator
class UserValidator : BaseValidator, IValidator {
 User userInstance;
 public UserValidator(User user) {
  userInstance = user;
 }

 public bool Validate() {
   // actual validation code here
   return true;
 }
}

Los clientes nunca deben lidiar con el almacenamiento de los objetos directamente.Se puede tratar con DTO directamente, pero cualquier objeto que tenga alguna lógica para el almacenamiento de información que no se ajusta en su objeto de negocio no debe ser llamado directamente por el cliente.

Echa un vistazo CSLA.net por Rocky Lhotka.

Bien, aquí estoy, el compañero de trabajo de Greg mencionado.

Greg se describen las alternativas que se han de considerar con gran precisión.Solo quiero añadir algunas consideraciones adicionales para la descripción de la situación.

El código de cliente puede ser inconscientes sobre datastorage donde el negocio de almacenamiento de los objetos, pero es posible, ya sea en el caso de que cuando sólo hay un datastorage, o hay varios datastorages para el mismo tipo de objeto (los usuarios almacenados en la base de datos local y en LDAP externo), pero el cliente no crea estos objetos de negocio.En términos de análisis del sistema, esto significa que no debe haber casos en los que la existencia de dos datastorages de objetos del mismo tipo pueden afectar caso de uso flujo.

Tan pronto como la necesidad de distinguir los objetos creados en diferentes almacenes de surgir, el componente de cliente debe ser consciente sobre la multiplicidad de los datos de almacenamiento en su universo, y que inevitablemente se convertirá en el responsable de la decisión que el almacenamiento de datos a utilizar en el momento de la creación del objeto (y, creo, objeto de la carga de un almacenamiento de datos).Capa de negocio puede pretender es hacer de esta decisión, pero el algoritmo de toma de decisiones se basará en el tipo y contenido de la información que llega desde el componente de Cliente, haciendo que el cliente de forma eficaz, responsable de la decisión.

Esta responsabilidad puede ser implementado en numerosas formas:puede ser un objeto de conexión de tipo específico para cada almacenamiento de datos;puede ser segregared métodos para llamar a la creación de nuevos BO instancias, etc.

Saludos,

Michael

CLSA ha sido alrededor de un largo tiempo.Sin embargo me gusta el enfoque que se analiza en el libro de Eric Evans http://dddcommunity.org/

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow