Avis sur la conception de la couche logique métier pour la fenêtre et de l'application basée sur le Web

Question

J'ai besoin des opinions sur le choix qui signatures pour ma couche d'affaires sur le web fonction:

CreateUser Fonction vide (Société UserCompany, nom de chaîne ...)

ou

CreateUser fonction void (int CompanyID, string name ...)

Si cela est une fenêtre basée je choisirais la fonction de prendre objet au lieu d'int parce que depuis la société déjà chargée à la forme de la fenêtre, pourquoi ne pas simplement l'utiliser. Aussi, je pense couche d'affaires devrait prendre des objets d'affaires et de sécurité de type (la prévention passe par mégarde dans 0 ou -1).

Mais d'autre part, si cela est une application basée sur le Web, ne id sera chargé sur des sites clients. Donc, il est une sorte de redondance à la charge de l'entreprise objet parce que finalement seulement COMPANYID sera enregistré dans le dabasebase de toute façon.

Espérons que ma description est pas trop confus = P Merci pour la lecture.

Answer 1

Je pense que vous avez répondu à votre propre question, cela dépend de la couche de présentation que vous utilisez. Mais quand vous voulez garder cette couche d'affaires générique, vous devrez aller avec l'ID.

Voici une autre idée. Personnellement, je aime à envelopper toutes les mutations dans les classes, que j'appelle les commandes. Vous pouvez par exemple avoir un CreateUserCommand héritant d'une commande de base. Cela vous permettra de l'utiliser comme ceci (je suppose C # ici):

var command = new CreateUserCommand();

command.UserCompanyId = companyId;
command.UserName = name;

command.Execute();

Lorsque cette logique d'emballage dans une commande est motif très agréable. Il vous permet de mettre un seul cas d'utilisation en une seule commande. Surtout quand la quantité de logique dans une commande grandit, vous apprécierez ce modèle, mais je l'ai trouvé très efficace pour les opérations CRUD ainsi.

Ce modèle vous permet également de faire abstraction du modèle transactionnel loin dans la classe de base. La classe de base peut envelopper un appel à exécuter dans une transaction de base de données. Voici une implémentation simple:

public abstract class CommandBase
{
    public void Execute()
    {
        this.Validate();

        using (var conn = ContextFactory.CreateConnection())
        {
            conn.Open();
            using (var transaction = conn.BeginTransaction())
            {
                using (var db = ContextFactory.CreateContext(conn))
                {
                    this.ExecuteInternal(db);

                    db.SubmitChanges();
                }

                transaction.Commit();
            }
        }
    }

    protected virtual void Validate() { }

    protected abstract void ExecuteInternal(YourDataContext context);
}

Et voici ce que le CreateUserCommand ressemblerait à ceci:

public class CreateUserCommand : CommandBase
{
    public int UserCompanyId { get; set; }
    public string UserName { get; set; }

    protected override void ExecuteInternal(YourDataContext context)
    {
       this.InsertNewUserInDatabase(context);
       this.ReportCreationOfNewUser();
    }

    protected override void Validate()
    {
        if (this.UserCompanyId <= 0) 
            throw new InvalidOperationException("Invalid CompanyId");
        if (string.IsNullOrEmpty(this.UserName))
            throw new InvalidOperationException("Invalid UserName");
    }

    private void InsertNewUserInDatabase(YourDataContext context)
    {
       db.Users.InsertOnSubmit(new User()
       {
          Name = this.UserName,
          CompanyId = this.CompanyId
       });
    }

    private void ReportCreationOfNewUser()
    {
        var message = new MailMessage();
        message.To = Configuration.AdministratorMailAddress;
        message.Body = "User " + this.Name + " was created.";

        new SmtpClient().Send(message);
    }
}

J'espère que cette aide.