Як організувати повторюваний код?

Моя команда створює безліч разових веб-форм. Більшість із цих форм просто надсилають електронне повідомлення, а деякі - просто записують в базу даних.

Наразі кожна форма живе у своєму окремому рішенні на сервері Visual Studio Team Foundation Foundation. Це означає, що у нас є близько 100 проектів різних форм, що ускладнює підтримку узгодженості. Кожна форма унікальна тим, що поля різні, але всі вони роблять майже те саме.

Я дивлюсь, щоб вони якось конденсувалися, і я дійсно міг би використати деякі вказівки.

• Чи варто спробувати створити один файл рішення з усіма нашими проектами форм? Сантехнічного коду не так багато, хоча я можу створити кілька допоміжних класів, щоб допомогти у форматуванні електронної пошти тощо. Було б дуже корисно мати спільний доступ до CSS, JavaScript, елементів управління та зображень між проектами.
• З огляду на те, що ми є магазином Microsoft, чи є якісь вигідні переваги, якщо ви хочете щось із MVC над веб-формами для цього конкретного сценарію? Мене продають за концепцією MVC в цілому, але чи допоможе мені ефективніше зібрати форму збору даних у 15 полях, якщо вся ця форма - це надіслати електронний лист? Форма, яка змусила мене замислитись над цим, мала вбудовану логіку для показу та приховування полів на основі відповідей користувача і, здається, було б менш ефективно використовувати MVC та jQuery.

Безперереактивне перенастроювання без тестів є складним та загрожує небезпекою.

Я б почав із:

• Написання тестових випадків, які охоплюють різні типи введення в ці форми та очікуваний результат. Здається, що це насправді не займе занадто багато часу, оскільки ви вважаєте, що більшість цих форм за функціональністю ідентичні або близькі до них.

• Запустіть ці тестові справи на 100 або більше форм (увімкніть покриття коду, щоб допомогти простежити шляхи коду).

Після цього ви зможете побачити, що ви можете сміливо переосмислити, тоді ви можете (приклад):

• Запустіть інструмент виявлення дублювання коду (не впевнений, як це називається у .NET, у Java у нас є CPD). Відразу видаліть 13 однакових форм. Тепер знову запустіть тести - Так! Усі вони проходять, за винятком форми 11, гаразд, тому ми ще не можемо її видалити.

• Видаліть усі локальні коди форматування електронної пошти та отримайте всі форми для виклику до загального модуля обробки електронної пошти. Виконайте тести, всі вони проходять за винятком одного, хмммм ОК .... UTF-8 символів, виправте це в загальному модулі, запускайте тести ще раз, так, у нас все добре!

промити і повторити.

Я б запропонував абстрагувати частину подання. Використовуючи Model / View / Controller, покладіть форми у View і запропонуйте їм використовувати той же контролер. Цей контролер може або виконати загальну дію, як-от надіслати електронний лист за типовою адресою, або перенаправити дані форми на контролер, який може. Таким чином, все, що вам потрібно зробити, щоб створити нову форму - це створити форму і направити вихід на цей контролер. Ця архетектура може міститися в одному проекті, який дозволить вам ділитися CSS та javascript, як ви згадували.

Щоб обробити форматування електронних листів, я б почав із створення загального форматера, скажімо, що просто перелічує назви та значення елементів форми, а також інший тип метаданих, як надісланий час, тощо. . Тоді, якщо вам дійсно потрібно більше користувальницької обробки, ніж це, додайте завод. Завод поверне інтерфейс форматера. Тоді, на фабриці, ви можете здійснити пошук форматера для цієї конкретної форми або повернути загальну, якщо конкретної не існує. Ця конструкція також полегшить тестування одиниці контролера, оскільки ви легко зможете поставити формат-формат для тестування.

До речі, я не ставлю адресу електронної пошти як аргумент із форми. Якщо вам потрібно надіслати декілька адрес, я б запропонував переглянути таблицю пошуку, яка містить усі форми та електронний лист для надсилання. Це може бути реалізовано в XML або в коді (я бачив і те, і інше, хоча я не впевнений, чи краще). Це допоможе уникнути отримання спамерами електронних адрес зі сторінки форми.