architecture - arquitectura - Espacio de nombres/estructura de la solución

building hashtags (6)

Hay un millón de formas de despellejar a un gato. Sin embargo, el más simple es siempre el mejor. ¿Qué camino es el más simple para ti? Depende de tus requisitos Pero hay algunas reglas generales que sigo.

Primero, reduzca la cantidad total de proyectos tanto como sea posible. Cuando compilas veinte veces al día, ese minuto extra se acumula.

Si su aplicación está diseñada para ser extensible, considere dividir sus ensamblajes a lo largo de las líneas de diseño frente a implementación. Coloque sus interfaces y clases base en un ensamblado público. Cree un ensamblaje para las implementaciones de estas clases de su empresa.

Para aplicaciones grandes, mantenga su lógica de UI y lógica de negocios separadas.

SIMPLIFIQUE su solución. Si parece demasiado complejo, probablemente lo sea. Combine, reduzca.

Me disculpo por hacer una pregunta tan generalizada, pero es algo que puede ser un desafío para mí. Mi equipo está a punto de embarcarse en un gran proyecto que, afortunadamente, arrastrará todas las bases de código aleatorias que se han desarrollado a lo largo de los años. Dado que este proyecto cubrirá la estandarización de entidades lógicas en toda la empresa ("Cliente", "Empleado"), tareas pequeñas, grandes tareas que controlan las tareas pequeñas y servicios de utilidad, estoy luchando por encontrar la mejor manera de estructurar el espacios de nombres y estructura de código.

Aunque supongo que no te daré suficientes detalles para continuar, ¿tienes algún recurso o consejo sobre cómo abordar la división lógica de tus dominios ? En caso de que sea de ayuda, la mayoría de esta funcionalidad se revelará a través de servicios web, y somos una tienda de Microsoft con los últimos artilugios y gadgets.

Estoy debatiendo una solución masiva con subproyectos para facilitar las referencias, pero ¿eso lo hará demasiado difícil de manejar?
¿Debería concluir la funcionalidad de la aplicación heredada o dejar eso completamente independiente en el espacio de nombres (por OurCRMProduct.Customer crear una clase OurCRMProduct.Customer frente a una clase Customer genérica)?
¿Debería cada servicio / proyecto tener su propio BAL y DAL , o debería ser un conjunto completamente separado al que todo hace referencia?

No tengo experiencia en la organización de proyectos de tan largo alcance, solo puntuales, así que estoy buscando cualquier orientación que pueda obtener.

Las soluciones grandes con muchos proyectos pueden ser bastante lentas de compilar, pero son más fáciles de administrar juntas.

A menudo tengo conjuntos de prueba de la Unidad en la misma solución que los que están probando, ya que tienden a hacer cambios juntos.

Los nombres de los ensamblados en .NET son los siguientes: Company.Project.XXXX.YYYY donde XXXX es Project y YYYYY es subproyecto, por ejemplo:

LCP.AdmCom.Common
LCP.AdmCom.BusinessObjects
LCP.AdmCom.Common.Dal

Tomamos esto de un libro llamado Directrices de diseño del marco por Krzysztof Cwalina (Autor), Brad Abrams (Autor)

Mi consejo, embarcado en una empresa similar, es no agonizar sobre los espacios de nombres.

Simplemente comience a desarrollar con algunas pautas sueltas importantes, ya que, como quiera que comience, su proyecto es orgánico y terminará reorganizando los espacios y las clases de nombres a lo largo del tiempo.

No pierdas el tiempo hablando demasiado sobre tu proyecto. Solo hazlo.

Para proyectos grandes, el enfoque que me gustaría adoptar es tener un espacio de nombres de dominio para mis objetos comerciales y luego usar Objetos de transferencia de datos (DTO) en mis capas donde se necesita el almacenamiento y la recuperación del objeto comercial. Un DTO es un objeto simple que no contiene ninguna lógica comercial.

Aquí hay un enlace que explica un DTO:

http://martinfowler.com/eaaCatalog/dataTransferObject.html

Recientemente experimenté exactamente lo mismo en el trabajo. Un montón de código ad-hoc que se debe estructurar y organizar.

Es realmente difícil al principio, ya que hay mucho. Creo que el mejor consejo que podría darles es invertir tiempo en él un viernes por la tarde, durante un par de semanas solo escogería una aplicación / fragmento de código, examinaría lo que había allí, pensaría en lo que podríamos hacer genérico, copiarlo, ponerlo en la nueva biblioteca donde creí que debería estar. Una vez que tenía todo el código dentro de una aplicación migrada, entonces trabajaría en la refacturación de la aplicación para trabajar desde el marco común. Esto a veces causaba problemas que debían corregirse, pero siempre que su exhaustivo no debería ser demasiado grande. un trato.

Pieza por pieza, esa es la única forma de hacerlo.

En términos de estructura, intenté imitar el espaciado de nombres de MS, ya que, en su mayor parte, es bastante lógico (por ejemplo, Company.Data , Company.Web , Company.Web.UI , etc.).

Uno de los principales beneficios es, probablemente, la cantidad de código duplicado eliminado. Sí, se requería un poco de refactorización en las aplicaciones, pero la base de códigos es mucho más sencilla y, en muchos sentidos, "más inteligente".

Otra cosa que noté es que a menudo tenía problemas para tratar de averiguar dónde poner cosas (en términos de espacios de nombres) ya que no estaba seguro de a qué pertenecía. Ahora que esto realmente me preocupaba, lo veía como un mal olor. Dado que la reorganización de todo ahora cae en el espacio mucho más agradable. Y con la (ahora muy pequeña cantidad) de código specfic de aplicación, se ponen en Company.Applications.ApplicationName Esto me ayuda a pensar mucho más en los objetos de negocio ya que no quiero demasiado en este espacio de nombres, así que se me ocurre más diseños flexibles.

Perdón por la publicación larga ... ¡Es un poco difícil!