Расширение существующего приложения ASP.NET 1.1 с использованием ASP.NET MVC - PullRequest
0 голосов
/ 17 февраля 2010

В настоящее время я работаю с большим, старым и крайне плохо написанным приложением ASP.NET 1.1, и постоянное обслуживание становится довольно большой проблемой. По сути, это достигает критической точки, и я не хочу расширять ее больше, чем нужно, как того требует бизнес. Исходя из моего опыта создания других проектов с нуля, он действительно подойдет для решения на основе ASP.NET MVC. О, как бы мне хотелось, чтобы мир был таким простым ...

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

Я читал посты, в которых говорится, что это вполне возможно, но в своих экспериментах я не находил это таким простым. Текущее приложение содержит несколько больших слоев доступа к данным и бизнес-логики, совместно используемых другими приложениями, которые производит компания. Они также написаны в 1.1 и не будут компилироваться в 2.0 (и уничтожат другие проекты, если я попытаюсь!), Поэтому я не могу обновить их. Поскольку я не могу этого сделать, я застрял с приложением, которое невозможно открыть даже в визуальной студии с поддержкой .NET 3.5. Новое приложение MVC также должно использовать эти слои.

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

Ответы [ 2 ]

2 голосов
/ 17 февраля 2010

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

0 голосов
/ 17 февраля 2010

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

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

...