OO Coding: ¿para usar Object Managers o no?

Question

un punto del estilo arquitectónico que me gustaría tener su opinión en favor:

Mi ORM me ha dado un objeto de usuario que corresponde a un usuario de mi sistema. Quería desarrollar un conjunto de métodos para manejar a los usuarios: GetByUsername(), Authenticate(), VerifyLoginPassword() etc. Sin embargo, me parece que algunos de estos métodos no pertenecen realmente a la clase User, p. Ej. GetByUsername() se siente al menos como un método estático de Usuario, pero ¿no sería más "limpio" tener otra clase, digamos "UserManager" que nos proporciona estas tareas de administración de usuarios? Parece un poco extraño que una instancia de Usuario contenga el método Authenticate(), por ejemplo, si es el sistema de seguridad el que realiza la autenticación.

Lo que me preocupa es que termine siguiendo este modelo hasta el punto en que la clase de usuario no es más que una estructura, y mis clases Administrador de usuarios y Administrador de seguridad realmente hacen todo el trabajo del método. No se siente muy "OO" tener todas estas clases de administrador manipulando objetos livianos.

¡Se agradecerá cualquier idea o relación con el estado de la técnica sobre este tema filosófico!

Answer 1

Parece que en ese punto en el que se está moviendo más allá de definir los objetos como "un perro es - un animal" y entrando en las definiciones de objetos en términos de funciones, responsabilidades y comportamientos.

Yo recomendaría este libro para ayudarle a hacer esa transición y realmente "conseguirlo ":

Object Design: Roles, Responsibilities, and Collaboration

que no tienen una respuesta a su problema, ya que es un elemento fundamental, tales decisión de diseño que realmente debería aprender acerca de la "imagen más grande". Este libro le dará una buena base en los principios y técnicas del diseño impulsado por la responsabilidad.

Enjoy,

Robert C. Cartaino

Answer 2

La situación que está describiendo está relacionada con si los objetos siguen el patrón de autoservicio o adaptador para guardarlos en un repositorio (es decir, la base de datos).

El autoservicio tendría los objetos guardados 'ellos mismos' como en myObjectInstance.Save(), mientras que el patrón del adaptador sería myObjectAdapter.Save(myObjectInstance).

El formulario Adaptador a menudo se ve favorecido porque elimina cualquier funcionalidad del repositorio de los objetos.

Answer 3

Martin Fowler tiene algunos views on this útiles.

La elección fundamental es entre el localizador de servicios y la inyección de dependencias. El primer punto es que ambas implementaciones proporcionan el desacoplamiento fundamental que falta en el ejemplo ingenuo: en ambos casos, el código de la aplicación es independiente de la implementación concreta de la interfaz del servicio. La diferencia importante entre los dos patrones radica en cómo se proporciona esa implementación a la clase de aplicación. Con el localizador de servicios, la clase de aplicación lo solicita explícitamente mediante un mensaje al localizador. Con la inyección no hay una solicitud explícita, el servicio aparece en la clase de aplicación, de ahí la inversión del control.

La inversión del control es una característica común de los marcos, pero es algo que tiene un precio. Tiende a ser difícil de entender y genera problemas cuando intenta depurar. Entonces, en general, prefiero evitarlo a menos que lo necesite. Esto no quiere decir que sea algo malo, solo que creo que necesita justificarse sobre la alternativa más directa.

Answer 4

Puede seguir refactorizar toda la funcionalidad de su clase de usuario, pero como se ha dicho que puede terminar con nada en él. En este punto, puede optar por evaluar todas las otras clases que ha creado, y luego hacer un juicio individual sobre cada una de estas clases, decidiendo caso por caso si estas clases contienen suficiente funcionalidad para garantizar una clase completamente nueva.

Si decide que algunas de estas clases son demasiado pequeñas, puede volver a colocar su funcionalidad en la clase Usuario. No veo nada de malo en tener, por ejemplo, una función Validar en el usuario, en lugar de tener una clase de validación del usuario con solo un método.

Answer 5

No parece muy "OO" tener todas estas clases de administrador manipulando objetos livianos.

No sé si esto es muy "OO", pero para mí se siente muy parecido a MVC y Separations-of-Concerns. Tener clases de negocios muy livianas (hasta el punto de que son solo contenedores de datos) y luego objetos de repositorio que las mueven es un patrón común.

Answer 6

Creo que está en el dinero cuando dice que esos métodos pueden no pertenecer al objeto de usuario. Los métodos Obtener/Buscar/Guardar pueden ser debatidos, pero soy de la opinión de que no deberían estar en el objeto de negocio y deberían hacerse con un Repositorio (el patrón de repositorio), o a través del Query Objects si no lo desea para abstraer su ORM en un repositorio.

En lo que respecta a la autenticación, sería mejor tener un conjunto de clases que sean responsables de la autenticación y que dejen totalmente fuera del objeto del usuario. Este conjunto de clases podría conocer el objeto del usuario o, mejor aún, deberían conocer un contrato como, por ejemplo, una Credencial.

Answer 7

Me gusta poner esto de una manera diferente. Estos métodos realmente no pertenecen al dominio ya que no hay lógica de negocios involucrada. Quiero usar el principio de comandos y la segregación consulta

GetByUsername() - es una consulta que realmente no necesita ninguna lógica de negocio

autenticación (pase), VerifyLoginPassword() - Se trata de la lógica de validación que no se supone para hacerse en el dominio. Consulte este documento Set Based validation in Domain