Class Design C# Разбиение пространства имен

Question

Я все еще пытаюсь разделить работу функции и как она применяется к созданию классов и включению пространства имен. У меня есть пользовательский класс SoftwareComponent, который при представлении пользователю чаще всего отображается как ListItem. Является ли создание метода ToListItem хорошей идеей? Я волнуюсь, потому что теперь я добавил зависимость в классе, которая потребует включения пространства имен System.Web.UI.WebControls.

public ListItem ToListItem() 
    { 
     ListItem li = new ListItem(); 
     li.Text = ComponentName + " (+" + ComponentCost + ")"; 
     li.Selected = Selected; 

     return li; 
    } 

Мой другой наклон создать ListItem из SoftwareComponent на основе его свойств вне самого класса. Просьба представить любые мысли о том, какой подход более уместен/лучше.

Answer 1

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

public static class SoftwareComponentExtensions 
{ 
    public static ListItem ToListItem(this SoftwareComponent component) 
    { 
     ListItem li = new ListItem(component.ComponentName + " (+" + component.ComponentCost + ")"); 
     li.Selected = component.Selected; 

     return li; 
    } 
} 

Answer 2

Это звучит как SoftwareComponent является областью объекта. - объект, который описывает «вещь» в мире приложение говорит в

Я стараюсь избегать этих объектов домена зависит ни от чего вне домена - это может быть ниже уровня (как он хранится? Сериализуется ли он? Сохраняется в базе данных) или на уровне пользовательского интерфейса.

Я согласен с тем, что это сложно сделать, довольно часто вы получаете отдельные иерархии классов для управления классами ui, сопоставлениями баз данных и т. Д. Таким образом, в зависимости от размера создаваемой вами вещи это компромисс, который включает в себя код пользовательского интерфейса или базы данных в объектах домена или для сохранения информации.

По конкретной проблеме вы имеете дело с методами расширения C# 3.5. Они ловкость рук при создании статических методов выглядят так, как будто они определены внутри класса - если они не имеют доступа к частным/защищенным материалам (они могут получить доступ к общедоступным методам, как и любой другой метод), вы можете уйти с ними , Я использую их для таких вещей, как вы хотите (методы «UI-Level» для объектов домена), которые, однако, определены в другом месте.

Но имейте в виду, что методы расширения - это не что иное, как синтаксический сахар для вас, старые старые статические методы в статическом классе.

Answer 3

У меня не было бы SoftwareComponent знать о ListItems и т. Д. Очевидно, что кто-то должен знать, как взять SoftwareComponent и застревать его части в ListItem, но я думаю, что это не проблема SoftwareComponent.

Спросите себя, если вы хотите добавить новый метод ToXYZ() каждый раз, когда вам нужно, чтобы он работал с другим элементом пользовательского интерфейса или создавал новый класс из его свойств. Наверное, вряд ли.