Помещение нового веб-интерфейса в старую базу данных толстых клиентов - PullRequest
3 голосов
/ 13 октября 2011

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

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

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

База данных является SQL Server и может легко использоваться в SQL Server 2008. Он очень богат хранимыми процедурами, функциями, несколькими триггерами и множеством таблиц с более чем 80 столбцами ... Но он достаточно нормализован. Мы хотим, чтобы и веб-приложение, и толстый клиент могли использовать одну и ту же базу данных. Это связано с тем, что если что-то плохо работает в веб-приложении, наши клиенты могут по-прежнему использовать толстый клиент и подключаться к нашим серверам. После того, как веб-приложение считается «стабильным», мы не рекомендуем толстый клиент.

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

А как на самом деле делать экраны? Есть ли способ проще, чем просто переписать форму в 80 полей в ASP.Net? Есть ли инструменты, которые могут сделать это проще?

В настоящее время планируется использовать ASP.Net WebForms (.Net 3.5). Я бы очень хотел использовать MVC, но никто в команде не знает этого, включая меня.

Ответы [ 4 ]

2 голосов
/ 13 октября 2011

Мы пока не уверены, будем ли мы внедрять автоматизированное тестирование с новым.

Внедрить автоматизированное тестирование.Какой смысл заменять одну глючную программу другой?

1 голос
/ 14 октября 2011

ASP.NEt формы не стартер, совершенно не подходит для чего-то подобного.Я рекомендую начать с чего-то вроде Создание API-интерфейса OData для StackOverflow, включающего XML и JSON, за 30 минут , а затем создать свое веб-приложение поверх , что (т. Е. Передать его клиенту, используйте JQuery / Silverlight).

1 голос
/ 14 октября 2011

У меня есть пара предложений:

1) создать сервисный уровень, чтобы абстрагироваться от зависимости от DAL. В ситуации, как вы описываете, наличие уровня косвенности для UI и BLL, на которые можно положиться, делает изменения БД намного безопаснее.

2) Создавайте автоматические тесты (как для юнитов, так и для интеграции), особенно если вы планируете внести довольно значительные изменения в уровни домена или персистентности (BLL / DAL). Чтобы сделать это действительно легко, вы всегда должны пытаться запрограммировать интерфейс. Это делает ваш код более гибким, а также позволяет вам использовать фреймворк-фреймворки (мне нравится Moq), чтобы ваши тесты действительно были модульными, а не интеграционными.

3) Взгляните на DDD (http://domaindrivendesign.org/), поскольку он вполне соответствует данному сценарию. По крайней мере, есть несколько очень полезных шаблонов, которые могут помочь сделать ваше приложение более гибким.

4) MVC совсем не сложно изучить, однако это простой способ получить настройку модульного тестирования для пользовательского интерфейса в результате архитектуры MVC (тестирование контроллера, а не представления). Тем не менее, нет никаких причин, по которым вы не можете тестировать веб-формы, это просто немного больше работы. MVC на самом деле является просто структурой пользовательского интерфейса / шаблоном дизайна (больше Model2, но мы можем пока игнорировать это). Это, так сказать, приближает вас к металлу, так как вы будете писать намного больше HTML и использовать модель («M») для передачи данных.

Для DDD взгляните на книгу Эрика Эванса: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1317333430&sr=1-1

Надеюсь, это поможет

1 голос
/ 13 октября 2011

Хороший вопрос, но "Медленно меняйте" структуру БД после того, как все на сайте попали , звучит как шутка ...
Я бы предпочел воспользоваться возможностью, чтобы создать новую структуру БД, написать сценарий миграции для пуленепробиваемой базы данных, который вы можете попробовать и переписать миллионы раз без каких-либо побочных эффектов для ваших клиентов, а затем написать, что вы хотите (толстый / веб ) на новом БД, протестируйте его и перенесите всех, когда он будет готов.

...