Espacio de nombres/estructura de solución

Question

Pido disculpas por hacer una pregunta tan generalizada, pero es algo que puede resultar un desafío para mí.Mi equipo está a punto de embarcarse en un gran proyecto que, con suerte, reunirá todas las bases de código únicas y aleatorias que han evolucionado 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, tareas grandes que controlan las tareas pequeñas y servicios públicos, estoy luchando por encontrar la mejor manera de estructurar el espacios de nombres y estructura de código.

Aunque supongo que no te estoy dando suficientes detalles para continuar, ¿Tiene algún recurso o consejo sobre cómo abordar la división lógica de sus dominios??En caso de que ayude, la mayor parte de esta funcionalidad se revelará a través de servicios web y somos un microsoft compre con los últimos artilugios y gadgets.

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

No tengo experiencia en la organización de proyectos de tan gran alcance, solo puntuales, por lo que estoy buscando cualquier orientación que pueda obtener.

Answer 1

Hay un millón de maneras de despellejar a un gato.Sin embargo, la más sencilla siempre es la mejor.¿Cuál es la forma más sencilla para ti?Depende de sus requisitos.Pero hay algunas reglas generales que sigo.

En primer lugar, reduzca el número total de proyectos tanto como sea posible.Cuando compilas veinte veces al día, ese minuto extra se suma.

Si su aplicación está diseñada para ser extensible, considere dividir sus ensamblajes según las líneas de diseño vs.implementación.Coloque sus interfaces y clases base en una asamblea pública.Cree un ensamblado para las implementaciones de estas clases en su empresa.

Para aplicaciones grandes, mantenga la lógica de la interfaz de usuario y la lógica empresarial separadas.

SIMPLIFICA tu solución.Si parece demasiado complejo, probablemente lo sea.Combinar, reducir.

Answer 2

Mi consejo, después de haberme embarcado en una empresa similar, es no preocuparse por los espacios de nombres.

Simplemente comience a desarrollar con algunas pautas importantes y flexibles, porque como sea que comience, su proyecto es orgánico y usted voluntad terminan reorganizando los espacios de nombres y las clases con el tiempo.

No pierdas el tiempo hablando demasiado de tu proyecto.Hazlo.

Answer 3

Recientemente experimenté exactamente lo mismo en el trabajo.Había mucho código ad hoc que necesitaba estructurarse y organizarse.

Al principio es muy difícil porque hay tantas cosas.Creo que el mejor consejo que podría dar es simplemente invertir tiempo en ello Mientras me relajaba un viernes por la tarde, durante un par de semanas simplemente elegía una aplicación o un fragmento de código, examinaba lo que había allí, pensaba en lo que podríamos hacer genérico, lo copiaba y lo ponía en la nueva biblioteca donde pensara. debería ser.Una vez que había migrado todo el código dentro de una aplicación, trabajaba en refactorizar la aplicación para que funcionara desde el marco común.Esto a veces causaba problemas que debían solucionarse, pero siempre que sea minucioso, no debería ser un gran problema.

Pieza a pieza, esa es la única manera de hacerlo.

En términos de estructura, intenté imitar el espacio de nombres de MS ya que en su mayor parte es bastante lógico (p. ej. Datos de la compañia , Empresa.Web , Empresa.Web.UI etcétera.

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

Otra cosa que noté es que a menudo tenía problemas al intentar descifrar dónde poner cosas (en términos de espacio de nombres) ya que no estaba seguro de a qué pertenecía.Ahora esto en realidad Me preocupaba, lo veía como un mal olor.Desde la reorganización, ahora todo encaja mucho mejor en el espacio.Y con la (ahora muy pequeña cantidad) de código específico de la aplicación, se colocan en Empresa.Aplicaciones.NombreAplicación Esto me ayuda a pensar mucho más en los objetos comerciales, ya que no quiero demasiado dentro de este espacio de nombres, por lo que se me ocurren diseños más flexibles.

Perdón por el post largo..¡Es una especie de divagación!

Answer 4

Nombramos los ensamblados en .NET de la siguiente manera Compañía.Proyecto.XXXX.YYYY donde XXXX es Proyecto y YYYYY es subproyecto, por ejemplo:

• LCP.AdmCom.Común
• LCP.AdmCom.BusinessObjects
• LCP.AdmCom.Common.Dal

Tomamos esto de una llamada de libro. Directrices de diseño del marco de Krzysztof Cwalina (Autor), Brad Abrams (Autor)

Answer 5

Para proyectos grandes, el enfoque que me gusta 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 almacenamiento y recuperación del objeto comercial.Un DTO es un objeto simple que no contiene ninguna lógica empresarial.

Aquí hay un enlace que explica un DTO:

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

Answer 6

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

A menudo tengo ensamblajes de prueba unitaria en la misma solución que los que están probando, ya que tiendes a realizar cambios en ellos juntos.