2008-12-11 25 views
9

¿Escribe createSomething() o addSomething()?CRUD vs AGUD vs AFUD ... ¿cuál es su convención de nomenclatura de preferencia

¿Escribe readSomething(), getSomething() o fetchSomething()?

Esto es totalmente una pequeña queja. En la sala de reuniones lo llamamos CRUD, pero en el código actual, se está convirtiendo en AGUD.

¿Cuál es su convención de nomenclatura de preferencia? ¿Importa?

thnx.

+0

CRUD es incompleta. CRUDO - Crear, Leer, Actualizar, Eliminar y Enumerar. (Tal vez CURDL si usa List). – Darron

Respuesta

2

Creo que depende del contexto del problema/tecnología - CREATE y ADD pueden ser diferentes.

Por ejemplo, PUEDO CREAR una etiqueta.

Y luego PUEDO AGREGAR esa etiqueta a una página.

Utilizamos repositorios para gestionar nuestros datos de acceso y de acuerdo con Eric Evans en su libro Domain Driven Design se debe añadir & Retire los objetos a un repositorio como si se trata de una colección en memoria - incluso si detrás de las escenas que está utilizando una base de datos .

Pero en respuesta a la pregunta original todavía hablo de CRUD porque soy un fanático de SQL en el fondo! :)

0

Creo que esto es bastante común. Nuestros DAO ciertamente son de los nombres de los métodos Add, Get, Update, Delete (establecer el estado en 'C'ancelled, etc.). En el nivel DB, son Inserts, Selects, Updates and Deletes - ISUD.

Podría ser Persist, Fetch, Delete. Persista agregando o actualizando según sea necesario.

0

Por lo general, "Obtener" para el nivel alto - obtener desde cualquier lugar: caché, disco, configuración. "Recuperar" obtiene el valor del almacenamiento persistente, normalmente llamado por "Obtener" si no está en la memoria caché.

0

I Crea algo y luego agrégalo a otra cosa. El complemento puede ser parte de la creación o, a veces, una actualización del objeto que lo contiene.

2

BREAD - explorar, leer, editar, agregar, eliminar.

6

prefiero CRUD sobre AGUD y AFUD.


CREATE Vs AÑADIR

Estamos tratando de utilizar estas dos palabras para indicar que estamos construyendo algo nuevo. CREAR no deja espacio para la interpretación; algo que no existía antes ahora se está construyendo. ADD puede ser un poco confuso porque podría implicar que estamos agregando algo que ya existe.


LEA vs.GET/FETCH

Para mí el problema con GET y FETCH aquí podría ser interprated como conseguir una única instancia de un objeto con el fin de modificarlo. Me gusta usar LEA porque es claro en el sentido de que quiero leer en una instancia de un objeto y que modificar la modificación del objeto requeriría una acción separada.

1

CRUD funciona mejor como un acrónimo. En la práctica, generalmente uso IACREUD:

  • Índice listas de los elementos disponibles para la edición; también muestra el formulario de eliminación.
  • Agregar es la vista que se usa para mostrar el formulario para agregar contenido;
  • Crear es el código de back-end que maneja el formulario Agregar;
  • Recuperar es la única vista utilizada en la aplicación de interfaz;
  • Editar es la vista que se usa para mostrar el formulario para editar contenido existente;
  • La actualización es el código de back-end que maneja el formulario de edición;
  • Borrar es el código de servidor que maneja el formulario Eliminar.

realmente no puedo pensar en una buena acrónimo de eso ..

+3

DACURIE, léase: Daiquiri? – totels

0

intento usar verbos más específicos cuando se me ocurren las apropiadas (que es bastante difícil a las 4 am). Para la mayoría de las cosas, agregar/editar/eliminar/obtener es lo suficientemente bueno y lo suficientemente corto.

0

Al final del día depende de usted como persona y es con lo que está satisfecho en su proyecto. Usualmente uso Get, Add, Search o algo similar a eso. Saludos Marca

0

depende de las preferencias y normas de la empresa. por lo general no depende de mí, y eso está bien para mí. un buen programador es flexible.

+0

Realmente, sus clientes individuales miran su código y dicen "¿puede hacer que 'cree' y 'agregue' ... eso simplemente no funciona para mí?" – typeoneerror

+0

Los clientes rara vez miran el código, ¿tiene clientes que consideren las convenciones de nomenclatura? En los muchos puestos de trabajo de programación que he tenido, generalmente corresponde al administrador del proyecto determinar las convenciones de nombres. He trabajado con gerentes anal que realmente se preocupan por esto, y he trabajado con compañías a las que no les importa (y eso se nota). Realmente no tengo preferencias y podría codificarlo de la manera que prefiera la COMPAÑÍA. Después de todo, es su código, no el mío. – D3vtr0n

+0

Nunca dije nada sobre los clientes que miran el código. ¿De dónde soñaste eso? – D3vtr0n

0

¿Escribes createSomething() o addSomething()?

utilizo createThing() cuando no existe algo, y addThing() si algo hace existe y vamos a añadir una cosa diferente a él.

¿Escribes readSomething(), getSomething() o fetchSomething()?

Utilizaría readThing() si estuviera leyendo bytes (o similar), getThing() si estoy accediendo a una propiedad y fetchThing() si estoy accediendo a una fuente externa.

Depende del contexto y la preferencia. LSS, Crear algo es definitivamente diferente de Agregar algo. Personalmente, siento que no son intercambiables.

+0

¿Pero realmente importa al final del día? Realmente no. La compañía todavía posee el código, y ellos determinan los estándares. A menos que, por supuesto, ejecute sus propias operaciones. Yo no, escribo código para vivir, no por diversión, por lo tanto, soy flexible en cualquier proyecto en el que desarrolle. – D3vtr0n

+0

Ejecuto mis propias operaciones, también escribo código para divertirme. De ahí mi pregunta sobre si alguien por encima de usted está preocupado por sus convenciones de nombres. Es una buena pregunta, creo; y definitivamente no es uno que salva a tu cobarde intento de insultar a la clientela o al "nivel empresarial" en el que trabajo. Un cliente es un cliente No rechazaría el trabajo porque es una banda que no me gusta. – typeoneerror

2

I prefieren readXXXX() sobre getXXXX(), porque getXXX() puede referirse a getter/setter métodos de bean, y puede crear confusión en el mantenimiento de código

Cuestiones relacionadas