Классы структурирования

Question

Окончательный вопрос: как классы обычно структурированы в приложениях?

В настоящее время я пишу тестовое банковское приложение в asp.net Например: у меня есть эти два класса. Один представляет собой счет, а другая утилита класса (Он имеет вещи делать со счетами, то есть получение счетов, обновление счетов и т.д.)

public Account { 
    int ID; 
    string Name; 
    double Balance; 
} 

public Accounts { 
    public List<Account> GetAllAccounts(); 
    public Account GetAccountByID(int AccountID); 
} 

в моем представлении слоя, каждый раз, когда я хочу, чтобы получить учетную запись Я использую:

Account editAccount = new Accounts().GetAccountByID(234); 

Вы можете видеть, что я создаю новый класс Accounts() для получения учетной записи. Что я должен делать на самом деле? Или это правильно? Соответствует ли статический класс этой потребности лучше?

Я чувствую, что это очень захламлено, и если оно становится больше, оно может быть неконтролируемым классами с похожими именами.

Как вы обычно структурируете это? Вы помещаете эти два метода в класс Учетные записи в класс учетной записи?

Любое понимание здесь было бы так здорово.

Благодаря

Answer 1

Из информации, которую вы должны предоставить мне бы GetAllAccounts и GetAccountByID статические и оставить их в классе счетов. Вы также можете создать статическую функцию для учетных записей, ответственных за создание и извлечение объектов Account. У вашего класса должна быть только одна причина для изменения (принцип единой ответственности).

Answer 2

Видя Account и Accounts классы меня беспокоят ... Я думаю, что Bank может быть лучшим именем для последнего. Таким образом, у вас есть Банк, который предоставляет доступ ко всем учетным записям или к отдельной учетной записи.

Answer 3

В общем, эти два метода войдут в класс Account. В этом случае нет веских причин иметь два класса. Если вы используете методы «Get», такие как ваш GetAccountByID, они должны быть установлены как static. Это позволяет их вызывать без создания экземпляра нового объекта учетной записи.

public static Account GetAccountByID(int AccountID); 

тогда вызов:

Account editAccount = Account.GetAccountByID(234); 

Answer 4

Опыт часто лучший гид, когда речь идет о таких вопросах, потому что дизайн API еще больше искусство, чем наука. Есть противоположные силы в игре для каждого класса вы дизайн:

• С одной стороны, мы хотим, чтобы классы, чтобы быть сплоченными инкапсулированных из связанных данных и поведения.
• С другой стороны, мы хотим придерживаться Single Responsibility Principle, чтобы избежать God Objects.

В вашем конкретном случае может показаться, что все поведение относится к учетным записям, что является аргументом для инкапсуляции всего этого в один класс.

Однако, по моему личному опыту, я часто считаю важным разделить создание объекта и срок службы от фактических типов. Это позволяет зависимым инъекциям (DI) и контейнерам DI заботиться о жизненном аспекте экземпляров, в то время как классы могут сосредоточиться на инкапсулировании данных и поведения.

В вашем конкретном случае класс Accounts очень похож на репозиторий , который является типом (часто абстрактным), который мы используем для поиска экземпляров в базах данных или другом постоянном хранилище. Они часто лучше моделируются как отдельные типы, чем классы, которые они извлекают.

В заключение обратите внимание, что в OOD вы не должны беспокоиться о взрыве класса. Предпочтительны многие небольшие классы с четкими обязанностями.

Answer 5

Вы ищете Repository pattern, который абстрагирует коллекцию объектов домена. Хранилище для вашего домена может выглядеть следующим образом:

public interface IAccountRepository 
{ 
    IList<Account> GetAll(); 

    Account GetById(int accountId); 

    // Insert and delete, if they apply 

    // Other account-specific queries and operations 
} 

Презентатор бы объявить зависимость от IAccountRepository:

public class EditAccountPresenter 
{ 
    private readonly IEditAccountView _view; 
    private readonly IAccountRepository _accounts; 

    public EditAccountPresenter(IEditAccountView view, IAccountRepository accounts) 
    { 
     _view = view; 
     _accounts = accounts; 

     _view.DataBinding += OnDataBinding; 
    } 

    private void OnDataBinding(object sender, EventArgs e) 
    { 
     _view.Account = _accounts.GetById(234); 
    } 
} 

Далее реализовать IAccountRepository однако вам нравится, и все это вместе, когда вы создаете выступающему :

var dataContext = new AccountDataContext("...connection string..."); 

this.Presenter = new EditAccountPresenter(this, new AccountRepository(dataContext)); 

Это помогает отделить определение операций от их фактической реализации. Он также позволяет вам выбрать, какой репозиторий вы предоставите ведущему, отделив его от реализации.

Гибкость этого подхода обеспечивает большую свободу и лучше подходит для изменения, чем непосредственное создание зависимостей. Это называется шаблоном Dependency Injection.

Answer 6

Как классы обычно структурированы в приложениях?

Poorly.

Что важнее выяснить, что именно должно быть статическим и так далее убедившись, что все отношения между различными классами отражают отношения между реальными вещами, которые они моделируют.

Является ли «Счетами» действительно то, что находится в модели вообще? Вам нужен класс для этого? Не могли бы вы просто иметь список учетных записей, а затем использовать на нем операторы запросов? Вместо метода, который получает учетную запись по его идентификатору, вы можете просто иметь список, а затем использовать accountList.First(x=>x.Id == 123). Возможно, это концепция, в которой вам не нужно даже моделировать.