Шаблоны MVC, MVP и решения с более чем одним проектом - PullRequest
3 голосов
/ 28 февраля 2012

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

Например: для MVP у меня может быть проект представления, проект докладчика и проект модели с решением. И похожий макет решения для MVC, где у меня может быть несколько проектов, формирующих решение. Я полагаю, что это также может относиться к решению MVVM, которое может содержать несколько проектов.

При работе с этими решениями каждый проект генерирует отдельную DLL. Таким образом, для решения, организованного по шаблону MVP, проект докладчика сгенерирует свою собственную .dll.

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

Я хотел бы знать:
1) Правильно ли я использую эти шаблоны или я совершенно не прав, организовывая свои решения, содержащие несколько проектов?

2) Должен ли я иметь весь свой код в одном проекте и организовать либо контроллеры / презентаторы / модели в папки, чтобы я генерировал один .exe или .dll для каждого решения. Проблема, с которой я сталкиваюсь при таком подходе, заключается в том, что для макета MVP я бы упустил возможность иметь разные представления с использованием моего проекта докладчика. (Например, представление WebSite, представление WebService).

3) Что является обычной практикой при использовании MVC / MVP или любого другого шаблона, где мы можем организовать решения, содержащие несколько проектов, чтобы я мог контролировать, кто вызывает мой код.

Ответы [ 2 ]

1 голос
/ 29 февраля 2012

Кстати, это отличный вопрос. Я работал с платформой ASP.NET MVC и использую MVP с веб-формами, а MVC Framework выходит на первое место. В следующей статье дается представление об обоих шаблонах или шаблоне 1, поскольку MVP - это скорее вариант / производная.

http://haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-mvc-and-mvp-but.aspx

  1. Если ваше приложение или бизнес требует, чтобы ваши детали MVC / MVP были разделены на другой проект, то это путь. Ваше повторное использование контроллера определенно является причиной для размещения этого в другом проекте.

  2. Visual Studio или MSsbuild предоставляет возможность объединения сборок. Это не то, о чем стоит беспокоиться, поскольку это никоим образом не повлияет на производительность вашего приложения, но, с другой стороны, может поставить вас перед проблемами разработки или совместного использования, которые будут в большей степени долговыми, чем несколько сборок.

http://www.hanselman.com/blog/MixingLanguagesInASingleAssemblyInVisualStudioSeamlesslyWithILMergeAndMSBuild.aspx

http://www.hanselman.com/blog/MixingLanguagesInASingleAssemblyInVisualStudioSeamlesslyWithILMergeAndMSBuild.aspx

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

Хороший показатель того, правильно ли вы используете шаблон, - это определение того, получаете ли вы преимущества шаблона.

1 голос
/ 29 февраля 2012

В предыдущем проекте MVP мы организовали, как вы упомянули, Views (в веб-проекте), Models, Presenters, Interfaces и т. Д. Для MVC вам будет лучше следовать структуре по умолчанию, заданной студией, по крайней мере для представлений и контроллеров.

...