Лучший способ объединить два идентичных веб-сайта ASP.NET? - PullRequest
1 голос
/ 17 июня 2010

У нас есть два веб-сайта, единственное отличие которых заключается в дизайне (разные изображения, стили, макеты и т. Д.), Но веб-структура файлов и кода CS одинакова, поэтому мы хотим упростить их обслуживание ...

Фактическая структура будет выглядеть следующим образом:

DefaultA.aspx
  DefaultA.aspx.cs
DefaultB.aspx
  DefaultB.aspx.cs
LoginA.aspx
  LoginA.aspx.cs
LoginB.aspx
  LoginB.aspx.cs

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

Еще один файл - общий доступ к cs (как наследование aspx, так и использование одного и того же cs), но мы никогда не делали и не видели его на каком-либо веб-сайте, поэтому мы задаемся вопросом, хороший ли это подход ...

Что ты думаешь?Есть ли другой способ улучшить производительность и облегчить разработку?

Ответы [ 5 ]

4 голосов
/ 17 июня 2010

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

2 голосов
/ 17 июня 2010

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

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

Grz, Kris.

1 голос
/ 18 июня 2010

У меня был похожий сценарий, в соответствии с которым я создал элементы управления .net, которые должны иметь альтернативную разметку и внешний вид на разных сайтах. Простого применения различных правил и тем CSS было недостаточно, поскольку разметка этих элементов управления может сильно измениться в зависимости от проектной документации и т. Д.

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

Теперь у вас есть сборка, которую вы можете поместить в несколько проектов, и все, что вам нужно сделать, это добавить новый элемент управления / страницу, которая наследуется от вашей сборки / типа, вместо того, чтобы иметь несколько кодов за файлами, которые делают одно и то же на другом веб-сайте. , Важно убедиться, что любые элементы управления, на которые вы ссылаетесь со своей страницы, присутствуют в вашей разметке, чтобы ASP .Net подключал элементы управления к коду за экземплярами в течение жизненного цикла страницы.

0 голосов
/ 15 сентября 2010

Вы уже приняли это как свой собственный ответ, но я хотел бы предложить вам, как я справлялся с подобной проблемой ранее при преобразовании двух «идентичных» веб-сайтов в единый проект для обработки обоих. У меня было два отдельных веб-домена, на которых размещались практически идентичные приложения, отформатированные под разные бренды для разных компаний. Мне нужно было одно решение с общим кодом, которое могло бы обслуживать, функционировать и регистрировать независимо в зависимости от обслуживаемого домена.

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

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

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

0 голосов
/ 15 сентября 2010

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

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

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