C Sharp / ASP.NET: вопрос о хорошей практике ООП - PullRequest
0 голосов
/ 23 августа 2011

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

Я немного не уверен, что делать в этой ситуации.У меня есть несколько веб-страниц, каждый из которых имеет собственный элемент управления GridView.Некоторая логика будет проходить через каждую строку и менять цвет строки в зависимости от определенных условий.Будет ли считаться плохой практикой, например, хранить один статический класс, инкапсулирующий эти изменения стиля, к которому будет обращаться каждая страница?Технически это означает, что этот класс будет модифицировать член другого класса.Как я должен идти об этом?Я бы предпочел не дублировать мой код в каждом классе, поскольку я стараюсь максимально придерживаться принципа СУХОЙ.

РЕДАКТИРОВАТЬ: Вот о чем я думаю.

public static class RowStyle
{
    public static void SetRed(GridViewRow row)
    {
        row.BackColor = Color.Red;
    }

    // More methods here
}

И каждая страница передаст много GridViewRows этому классу, а затем их модифицируют.

Ответы [ 5 ]

2 голосов
/ 23 августа 2011

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

Например, следуя вашему примеру, IMO будет в порядке

public static class Colorizer
{
    public static void Colorize(GridView gv)
    {
      // do you're funky logic here.
    }
}

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

Однако, это было бы плохо, плохо, плохо:

public static class Colorizer
{
    private static bool haveIAlreadyColorized = false;
    public static void Colorize(GridView gv)
    {
       if(!haveIAlreadyColorized)
            // do you're funky logic here.
    }
}
0 голосов
/ 23 августа 2011

Я бы инкапсулировал изменения стиля в одном месте (мой выбор был бы web.config) и создал бы вспомогательный метод, который принимает экземпляр GridView в качестве параметра. Единственная цель этого вспомогательного метода в жизни - прочитать информацию о стиле из файла конфигурации, чтобы применить его к переданному экземпляру GridView.

Любые страницы, содержащие GridView, к которому должны применяться эти изменения стиля, будут вызывать вспомогательный метод.

0 голосов
/ 23 августа 2011

Я думаю, что было бы неплохо иметь статический класс с таким методом:

public static System.Drawing.Color GetRowColor(GridRow row)
...

Если правила , которые определяют значение цвета, являются глобальными, то этоэто правильно.

0 голосов
/ 23 августа 2011

Если вы будете следовать тем же цветовым кодам, вы можете следовать этому:

  1. Создать общий класс. Сделай это статичным.

  2. Создайте метод, который будет вызываться в событии, связанном с строкой, и в зависимости от события вы можете изменить цвет

0 голосов
/ 23 августа 2011

Я бы порекомендовал создать пользовательский UserControl, содержащий ваш GridView, и добавить туда всю связанную логику. Это лучший способ сделать это на платформе ASP.NET.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...