Jak klasyfikowałbyś ten typ projektu do zajęć?

Question

Następujący typ projektu, który widziałem, ma w zasadzie "cienkie" klasy, z wyjątkiem dowolnego zachowania. Klasa dodatkowa służy do wstawiania/aktualizacji/usuwania/pobierania.

Czy to źle? Czy to anty 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); 

     } 

} 

Answer 1

Chciałbym zaklasyfikować go jako obiekt domeny lub obiekt biznesowy. Jedną z zalet tego rodzaju projektu jest to, że utrzymuje on model agnostyczny dla dowolnej logiki biznesowej i można go ponownie wykorzystać w różnych środowiskach.

Druga klasa może zostać sklasyfikowana jako DAO (Data Access Object).

Ten wzorzec nie jest w ogóle antyoptyczny i jest szeroko stosowany.

Answer 2

Wydaje mi się, że implementujesz domain model i data-access object. To dobry pomysł.

Answer 3

Podczas gdy twoja klasa user.cs użycza się na domain transfer object, klasa Users.cs jest zasadniczo miejscem, w którym możesz zastosować reguły biznesowe w ramach data-access objects.

Możesz pomyśleć o konwencji nazewnictwa swoich klas wraz z przestrzeniami nazw. Kiedy patrzę na plik users.cs, zakładam, że będzie to w zasadzie klasa do pracy z listą użytkowników.

Inną opcją będzie zaglądanie do Active Record Pattern, która połączy dwie utworzone przez siebie klasy.

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"]; 
    } 
} 

Answer 4

Wygląda na to może być repository pattern to wydaje się być coraz bardziej powszechny wzorzec i jest używany do świetnie wpływa w Rob Conery's Storefront przykład Asp.Net MVC aplikacji.

Zasadniczo abstrakcjonujesz swój kod dostępu do danych z dala od Modelu, co jest ogólnie rzeczą dobrą. Chociaż miałbym nadzieję na odrobinę odwagi do klasy modelowej. Również z poprzednich doświadczeń, nazywając go Użytkownicy są mylące, UserRepository może być lepsza. Warto również rozważyć usunięcie statycznego (co jest gorącą debatą), ale ułatwia kpiny. Dodatkowo repozytorium powinno implementować interfejs, aby można było go sfałszować, a następnie zastąpić fałszywym później.

Answer 5

W rzeczywistości nie jest obiektowo zorientowany, ponieważ obiekt jest niczym innym, jak kumulacją danych. Nie to jest straszne.

Answer 6

Pierwsza klasa jest anty-OOP, ponieważ zawiera dane bez zachowania, typowy przykład anemic domain model. Jest to typowe dla osób, które programują proceduralnie w języku OO.

Jednak opinie są podzielone na to, czy ma sens logika dostępu DB do samego modelu domeny (aktywny wzorzec rekordu) lub, jak w kodzie, do oddzielnej klasy (wzorzec obiektu dostępu do danych), ponieważ dostęp do bazy danych jest oddzielną kwestią techniczną, która niekoniecznie musi być ściśle powiązana z modelem domeny.