Como você classifica este tipo de design para as classes?

votos
5

O seguinte tipo de projeto que eu tenho visto, basicamente, tem aulas fino, com exclusão de qualquer tipo de comportamento. A classe secundária é usada para inserir / update / delete / get.

Isso é errado? É anti OOP?

User.cs

public class User
{

    public string Username { get; set; }
    public string Password { get; set; }
}


Users.cs


public class Users
{
    public static User LoadUser(int userID)
    {
            DBProvider db = new DBProvider();
            return dp.LoadUser(userID);

        }

}
Publicado 19/05/2009 em 21:53
fonte usuário
Em outras línguas...                            


6 respostas

votos
3

Enquanto sua classe user.cs está prestando-se em direção a um objeto de transferência de domínio , a classe Users.cs é essencialmente onde você pode aplicar regras de negócio dentro dos objetos de acesso a dados .

Você pode querer pensar sobre a convenção de nomenclatura de suas classes, juntamente com os namespaces. Quando eu olhar para um users.cs, eu estou supondo que ele será essencialmente uma classe para trabalhar com uma lista de usuários.

Outra opção seria a de olhar para o Active Record , que combinaria as duas classes que você criou.

User.cs

public class User
{
    public string Username { get; set; }
    public string Password { get; set; }

    public User(int userID)
    {
        //data connection
        //get records
        this.Username = datarecord["username"];
        this.Password = datarecord["password"];
    }
}
Respondeu 19/05/2009 em 22:07
fonte usuário

votos
1

A primeira classe é anti-OOP porque contém dados sem comportamento, um exemplo típico de um modelo do domínio anémica . É típico de pessoas que fazem programação procedural em uma linguagem OO.

No entanto, as opiniões estão divididos sobre se faz sentido ot colocar lógica de acesso a DB no próprio (Active Record) modelo de domínio ou, como no seu código, em uma classe separada (padrão Data Access Object), já que o acesso DB é uma unidade técnica preocupação que não deve necessariamente estar estreitamente associadas ao modelo de domínio.

Respondeu 19/05/2009 em 22:32
fonte usuário

votos
1

Acho que você está implementando um modelo de domínio e um objeto de acesso a dados . É uma boa ideia.

Respondeu 19/05/2009 em 22:00
fonte usuário

votos
1

Eu classificá-lo como um objeto de domínio ou objeto de negócios. Uma das vantagens deste tipo de projeto é que ele mantém o agnóstico modelo de qualquer lógica de negócios e eles podem ser reutilizados em diferentes tipos de ambientes.

A segunda classe poderia ser classificado como um (Data Access Object) DAO.

Este padrão não é anti-oop em tudo e é amplamente utilizada.

Respondeu 19/05/2009 em 21:56
fonte usuário

votos
0

Não é realmente orientada a objeto, em qualquer sentido, uma vez que o objeto não é senão um amontoado de dados colem. Não que isso seja uma coisa terrível.

Respondeu 19/05/2009 em 22:29
fonte usuário

votos
0

Parece que ele poderia ser o padrão de repositório este parece ser um padrão cada vez mais comum e é usado para grande efeito na montra de Rob Conery exemplo Asp.Net MVC aplicativo.

Você está abstraindo basicamente o seu código de acesso de dados de distância do modelo, que é uma coisa boa, em geral. Embora eu poderia esperar um pouco de coragem para a classe modelo. Também a partir de experiências anteriores, chamando-o de usuários é confuso, UserRepository pode ser beter. Também pode querer considerar a remoção de estática (que é um debate quente), mas faz zombando mais fácil. Além disso, o repositório deve ser implementação de uma interface que você pode zombar-lo e, portanto, substituí-lo com um falso mais tarde.

Respondeu 19/05/2009 em 22:09
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more