Organizar clases de Apex en el espacio de nombres

Question

¿Hay alguna forma en Salesforce para agrupar clases de Apex en un paquete o espacio de nombres? ¿Podemos usar el paquete administrado para fines internos?

Answer 1

Esta es una limitación en la pila de Force.com que hace que los proyectos de tamaño mediano y grande sea doloroso, si no poco práctico. El uso de paquetes administrados para obtener un prefijo de paquete realmente no resuelve ningún problema, por lo que realmente no vale la pena.

Por lo general, trato de organizar un proyecto en un nivel plano de espacios de nombres. En lugar de espacios de nombres reales, le daré a cada posible espacio de nombre un nombre de 3-5 caracteres, para ser utilizado como prefijo. Cualquier clase que pertenezca al "espacio de nombres" se prefije. Por ejemplo, si necesito un payroll espacio de nombres, usaría un PYRL prefijo. Una clase llamó PaycheckCalculator convertirse en PYRL_PaycheckCalculator.

La ventaja práctica de este tipo de convención es que ayuda a prevenir los enfrentamientos de nombres y las clases se agrupan por su "espacio de nombres" cuando se ve en una lista ordenada, como en un IDE, o configuración> Desarrollar> Clases Apex

Desafortunadamente, varios principios básicos de OO todavía están fundamentalmente rotos. Probablemente el más importante es que cada clase forma una dependencia implícita de cada otra clase a la que tiene visibilidad, que es todos de ellos.

Me encantaría saber cómo otros han trabajado en torno a esta limitación.

Answer 2

Bueno, tu pueden Use paquetes administrados, pero como Jeremy mencionó, realmente no te compra mucho. Por supuesto, los paquetes administrados son esenciales para desarrollar aplicaciones que sean listadas públicas para vender en AppExchange. Pero internamente, es realmente un problema de toda la organización, ya que una vez que crea un paquete administrado con un prefijo, todo lo que toca cualquier otra parte se estampa con el mismo prefijo de espacio de nombres, incluidos todos los objetos personalizados. Y peor, no puede acceder al código en un paquete administrado desde fuera de El paquete administrado (que en realidad es el objetivo de ellos en primer lugar).

Aunque no es la solución más bonita, lo que personalmente hago es mantener numerosos orgs con nombre con diferentes propósitos, aplicaciones y clases de servicios públicos. Cuando necesito una clase de utilidad en una organización, digamos que estoy creando una nueva aplicación destinada al AppExchange, haré una exportación/importación de eclipse de la organización de utilidad en cuestión. Definitivamente parece extraño, pero tener una biblioteca de organizaciones es la mejor manera que he logrado hacer un seguimiento de todo y administrar la organización "interna". Pero el resultado final es realmente solo una operación glorificada de copias de copia entre las tiendas de código arbitrarias.

Answer 3

Me enfrenté a desafíos similares mientras trabajaba en grandes proyectos, escribí esta publicación de blog en algún momento para compartir el enfoque que estoy siguiendo ahora: http://www.tgerm.com/2011/11/apex-class-naming-convention-suggestion.html