Лично я верю, что хороший стиль будет сохранять цель шаблона MVP и поддерживать код в чистоте.
Если я правильно понимаю, ваше свойство CustomList будет иметь тип вашего пользовательского элемента управления. Предоставление такого свойства интерфейсом представления заставило бы весь код, работающий с этим интерфейсом (презентатор), зависеть от вашего элемента управления (и ссылаться на него как на зависимость). Это возможно и, вероятно, будет работать достаточно хорошо для ваших требований, но это противоречит схеме проектирования MVP. Возможно, вы захотите разделить реализацию представления и докладчика на разные сборки. Но оба должны ссылаться на ваш контроль. MVP был разработан для разделения специфических взаимодействий пользовательского интерфейса и специфических возможностей управления (которые в большинстве случаев зависят от платформы / поставщика) и для того, чтобы скрыть их от бизнес-логики (докладчик).
В вашем сценарии я бы предложил предоставить докладчику метод AddItem - ответственность реализации представления заключается в том, чтобы обрабатывать пользовательские элементы управления или любые вопросы, связанные с отображением данных. С другой стороны, докладчик сосредоточится на извлечении данных и выполнении бизнес-логики.
Я подозреваю, что вам не придется одновременно поддерживать разные технологии пользовательского интерфейса (например, ASP.NET Web Forms, WPF / Silverligth или ASP.NET MVC), но если вам гипотетически придется перенести веб-сайт ASP.NET MVC на WPT-приложение destktop и придерживайтесь шаблона проектирования MVP, тогда вам (в лучшем случае) придется реализовывать интерфейс представления только в каждой технологии пользовательского интерфейса, сохраняя одну и ту же кодовую базу для докладчика, служб и всех элементов бизнес-логики ( На самом деле переход от ASP.NET MVC к настольному компьютеру был бы настоящим приключением, но пример должен подчеркнуть, что презентатор и бизнес-логика не должны быть изменены).
PS. Некоторые фреймворки в Java имеют абстрактные интерфейсы (модели пользовательского интерфейса), представляющие компоненты пользовательского интерфейса, и могут повторно использоваться в различных технологиях пользовательского интерфейса. В таких случаях было бы приемлемо представить компонент пользовательского интерфейса через интерфейс модели пользовательского интерфейса (который он должен реализовывать).