Est-il préférable d'avoir des actions de création et de modification séparées ou de combiner la création et la modification en une seule?

15

Nous utilisons ASP.NET MVC 2 avec une couche de présentation contrôleur / vue et un modèle composé d'une couche logique métier, d'une couche d'accès aux données [procédures stockées et classes / méthodes pour parler aux procédures stockées].

Dans la couche de gestion et au-dessus pour la plupart des applications, Edit semble être capable de représenter à la fois la création d'un objet et l'édition d'un objet. Cela coïncide bien avec notre modèle de conception de référentiel qui définit une méthode "Enregistrer". Nous pouvons simplement vérifier dans la procédure stockée si l'ID est 0, puis créer un nouvel objet s'il est 0, sinon nous pouvons simplement mettre à jour l'objet existant, car l'ID de catégorie doit correspondre à un.

Le principal point de discussion est de savoir s'il est plus judicieux de diviser la modification qui inclut la création en ses parties distinctes de la création et de la modification au-delà de la couche DAL.

Un exemple évident peut être montré comme des itinéraires:

Créer - http: // someurl / somearea / edit / 0

Modifier - http: // someurl / somearea / modifier / 254

contre.

Créer - http: // someurl / somearea / create

Modifier - http: // someurl / somearea / modifier / 254

Existe-t-il des normes ou des meilleures pratiques établies à cet égard?

Je sais que c'est un petit détail, mais je pense que c'est logistiquement important.

design design-patterns asp.net-mvc

— Joshua Enfield
source

4

Personnellement, je pense que des actions de création et d'édition séparées sont une mise en œuvre beaucoup plus propre (et peut-être plus facile à maintenir).

— Adam Lear

1

Une méthode dans le DAL, deux pour l'API si cela a du sens.

— CaffGeek

Eh bien, de mon point de vue, la création et l'édition séparées viennent naturellement à mvc et suivre cette approche donne beaucoup d'avantages à utiliser le mvc au maximum et cela devrait être l'objectif de tout le monde.

— maz3tt

5

Je dirais certainement qu'il vaut la peine de séparer Créer / Modifier, sinon pour obéir au principe de responsabilité unique .

On pourrait prétendre qu'il y a un meilleur référencement en ayant également la bonne action dans l'url.

Ne pas séparer les deux rendrait également le code plus difficile à tester.

Un nouveau programmeur lisant le code ne trouverait probablement pas le code très intuitif pour créer des objets dans une méthode "edit", cela n'a tout simplement pas de sens sémantiquement. Je peux cependant sympathiser avec la méthode Save () dans le DAL.

En y réfléchissant, je ne vois pas vraiment les avantages de tout mettre dans une méthode Edit.

— nillls
source

4

Je préfère généralement créer une Saveméthode dans le DAL, mais en fait implémenter le Create/ Edit/ Deleteséparément.

Par exemple, ma Saveméthode vérifie l'état de l'objet et appelle la méthode Create / Edit / Delete en fonction de ce qui est nécessaire

switch(obj.State)
{
    case ObjectState.New:
        CreateObject(obj);
        break;
    case ObjectState.Modified:
        UpdateObject(obj);
        break;
    case ObjectState.Deleted:
        DeleteObject(obj);
        break;
}

Cela me permet d'appeler une seule méthode générique pour enregistrer n'importe quel objet, mais garde toujours la mise en œuvre de chacun (Créer, Modifier, Supprimer) séparée.

— Rachel
source

Comment pourriez-vous dire que c'est une suppression?

— NoChance

Mes objets ont généralement une Statepropriété. Par exemple, cliquer sur le Deletebouton marquera l'objet comme supprimé, puis appelezSaveChanges()

— Rachel