Частичные классы в C#

Question

Есть ли хорошие применения частичных классов вне сценариев сгенерированных сценариев webforms/winforms? Или эта функция в основном поддерживает это?

Answer 1

Отчасти для поддержки сценариев (WebForms, WinForms, LINQ-to-SQL и т. Д.) Сгенерированный код с кодом программиста.

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

Я считаю частичные классы чрезвычайно полезными. Обычно они используются для расширения автогенерируемых классов. Я использовал их в одном проекте с тяжелыми модульными тестами. У моих классов UT были сложные зависимости, и было не очень удобно разделять код на несколько классов. Конечно, лучше использовать наследование \ состав, но в некоторых случаях частичные классы могут быть полезными для ралли.

Answer 6

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

Answer 7

Исправление, как указал Мэтт, обе части частичной части должны находиться в одной и той же сборке. мой плохой.

Answer 8

Я использую его в слое доступа к данным. Сгенерированные классы, такие как mapper, и запросы частичного. Если мне нужно добавить метод сопоставления, например, чтобы сделать фантазийную загрузку, которая не сгенерирована, я добавляю ее в пользовательский класс.

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

Answer 9

Я просто нашел использование для частичных классов. У меня есть класс [DataContract], который я использую для передачи данных клиенту. Я хотел, чтобы клиент мог отображать класс определенным образом (текстовый вывод). поэтому я создал частичный класс и переопределил метод ToString.

Answer 10

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

Мы также использовали их для группировки переопределений запаса или скрытия набора свойств. Такие вещи. Это удобный способ смешивания в изменении запаса (просто скопируйте файл и измените имя частичного класса на целевой класс - если конечно класс тоже будет частичным).

Answer 11

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

Возьмите WinForms или Typed-DataSets, например (или любой дизайнер, если на то пошло). Каждый раз, когда вы вносите изменения в конструктор, он сериализует соответствующий код в файл. Допустим, вам нужно предоставить несколько дополнительных методов, о которых генератор ничего не знает. Если вы добавите его в сгенерированный файл, ваши изменения будут потеряны при следующем его создании.

Проект, над которым я сейчас работаю, использует генерацию кода для всех DAL, BLL и бизнес-объектов. Однако генератор получает только 75% информации. Остальная часть должна быть ручной кодировкой (например, пользовательская бизнес-логика). Я могу предположить, что каждый класс BLL имеет метод SelectAll, поэтому его легко сгенерировать. Однако у моего клиента BLL также должен быть метод SelectAllByLocation. Я не могу поместить это в свой генератор, потому что он не является общим для всех классов BLL. Поэтому я генерирую все мои классы как частичные классы, а затем в отдельном файле я определяю свои собственные методы. Теперь по дороге, когда меняет структура, или мне нужно восстановить мой BLL по какой-то причине, мой пользовательский код не будет уничтожен.

Answer 12

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

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

Answer 13

Я работал над проектом пару лет назад, когда у нас был типизированный класс DataSet, в котором было тонны кода: Методы в DataTables, методы в TableAdapters, объявления экземпляров TableAdapter, вы называете это. Это была крупная центральная точка проекта, в которой каждый должен был работать часто, и было много конфликтов с контролем источника над частичным файлом кода класса.

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

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

Answer 14

Везде, где бы использовал #region разделы, прежде чем, вероятно, имеет смысл как отдельные файлы в частичных классах.

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

Answer 15

Как правило, я считаю его запахом кода.

Если ваш класс такой сложный, его можно, вероятно, разбить на более мелкие повторно используемые компоненты.

Или это означает, что theres нет иерархии наследования, где должен быть один.

Для сценариев генерации кода это хорошо, но я думаю, что генерация кода - еще один запах кода.

Answer 16

EDIT: DSL Tools для Visual Studio использует частичные классы.

Таким образом, это функция, используемая многими автоматическими генерируемыми кодами. Вместо использования #region автоматически сгенерированный код переходит в один файл, а код пользователя (также называемый настраиваемым кодом) переходит в другой и даже в разные каталоги, так что разработчик не путается с таким количеством бессмысленных файлов.

Это хорошо, чтобы этот выбор, который вы можете комбинировать - но не обязательно использовать -с наследование

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

Answer 17

Как уже упоминалось ранее, я тоже считаю, что это запах кода.

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

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

Answer 18

Другим возможным использованием для частичных классов было бы использование частичных методов для выборочного удаления методов с использованием условной компиляции - это было бы прекрасно для сценариев диагностики отладочного режима или сценариев специализированного тестирования.

Вы можете объявить частичный метод вроде абстрактного метода, а затем в другом частичном классе, когда вы вводите ключевое слово «partial», вы можете использовать Intellisense для создания реализации этого метода.

Если вы окружите одну часть условными инструкциями сборки, вы можете легко отключить только отладочный или тестовый код. В приведенном ниже примере в режиме DEBUG вызывается метод LogSomethingDebugOnly, но в сборке релиза это похоже на то, что этот метод вообще не существует - хороший способ убрать диагностический код от производственного кода без кучи ветвления или несколько условных блоков компиляции.

// Main Part 
public partial class Class1 
{ 
    private partial void LogSomethingDebugOnly(); 

    public void SomeMethod() 
    { 
     LogSomethingDebugOnly(); 
     // do the real work 
    } 
} 

// Debug Part - probably in a different file 
public partial class Class1 
{ 

    #if DEBUG 

    private partial void LogSomethingDebugOnly() 
    { 
     // Do the logging or diagnostic work 
    } 

    #endif 
} 

Answer 19

Я в конце игры ... но только мои 2 цента ...

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

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

Answer 20

может быть слишком поздно, но, пожалуйста, дайте мне добавить мои 2 цента тоже:

* .При работе над большими проектами, распространяясь класс по отдельным файлам позволяет нескольким программистам работать над ним одновременно.

*. Вы можете легко написать свой код (для расширенной функциональности) для генерируемого класса VS.NET. Это позволит вам написать код, который вам нужен, без ворчания с кодом, сгенерированным системой.