Краща архітектура програми ASP.NET WebForms

Я написав портал ASP.NET WebForms для клієнта. Проект розвивався, а не був належним чином спланований та структурований з самого початку. Отже, весь код з’єднується разом у межах одного проекту та без жодних шарів. Клієнт тепер задоволений функціоналом, тому я хотів би переробити код таким, що буду впевнено випускати проект. Оскільки, здається, існує багато різних способів проектування архітектури, я хотів би отримати декілька думок щодо найкращого підходу.

ФУНКЦІОНАЛЬНІСТЬ

Портал дозволяє адміністраторам налаштовувати шаблони HTML. Інші асоційовані "партнери" зможуть відображати ці шаблони, додавши на свій сайт код IFrame. У цих шаблонах клієнти можуть зареєструвати та придбати товари. API був реалізований за допомогою WCF, що дозволяє і зовнішнім компаніям взаємодіяти з системою. Розділ Адміністратор дозволяє адміністраторам налаштувати різні функціональні можливості та переглядати звіти для кожного партнера. Система розсилає клієнтам рахунки-фактури та повідомлення електронною поштою.

СУЧАСНА АРХІТЕКТУРА

В даний час використовується EF4 для читання / запису в базу даних. Об'єкти EF використовуються безпосередньо у файлах aspx. Це сприяло швидкому розвитку, поки я писав сайт, але, мабуть, неприйнятно тримати його таким, оскільки він щільно з’єднує db з інтерфейсом користувача. Конкретна бізнес-логіка додана до часткових класів об'єктів EF.

ЗАПИТАННЯ

Метою рефакторингу буде зробити сайт масштабованим, легкодоступним та безпечним.

1. Яка архітектура була б найкраща для цього? Опишіть, будь ласка, що має бути у кожному шарі, чи слід використовувати шаблон DTO / POCO / Active Record тощо.

2. Чи існує надійний спосіб автоматичної генерації DTO / BO, щоб будь-які майбутні удосконалення було легко здійснити, незважаючи на додаткові шари?

3. Чи було б вигідно перетворити проект з WebForms в MVC?

Шаблон ASP.NET MVP - найкраща архітектура для довгострокового застосування веб-форм ASP.NET. Це вступає в гру з концепцією "розділення проблем", що фактично є тенденцією, що стоїть за моделями MV *.

Питання на те, для чого його використовувати? - детально розглянуто в цій публікації - ASP.NET MVP

• Початок роботи з тестуванням програми ASP.NET Webforms
• Компроміси між MVP і MVC
• Кінець плутанини: MVP проти MVC

1. Використовуйте MVP-шаблон для роздільного та логічного та інтерфейсу, щоб у майбутньому ви могли перейти до іншої технології інтерфейсу, повторно використовуючи існуючу логіку
2. Використовуйте шаблон сховища між BL і DAL, щоб ви могли перейти на будь-яку RDBS, що повторно використовує бізнес-логіку
3. принести окремі шари (Dlls) для BO і DAL, що мінімізує обслуговування.

Як згадував Ельюсубов, модель MVP може бути чудовою.

Ключова концепція - це вилучення більшої чи всієї вашої логіки з коду. Логіка не повинна прив'язуватися до сторінки. Що робити, якщо вам потрібно повторно використовувати логіку з однієї сторінки на іншу? Вас спокусить скопіювати та вставити. Якщо ви це робите, то ваш проект стане реалізовуваним.

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

Також переконайтеся, що ваш доступ до даних не відрізняється від вашої логіки бізнесу. Створіть рівень даних і починайте рефакторинг також на цьому кінці. Оскільки ви використовуєте EF4, це менше проблеми, оскільки EF має вже мати цей кінець окремо. Ви повинні легко перемістити всі файли EF в інший проект і просто додати посилання на проекти, які цього потребують. Окрім того, вам може знадобитися посилання на вашу модель даних в інших проектах.

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

Редагувати

Ви запитували про наявність коду за спадковим класом бізнес-логіки. Це неможливо зробити, оскільки код за сторінкою "є -а". C # не дозволяє множинне успадкування, тому клас, що знаходиться за кодом, не може бути як сторінкою, так і спеціальним об'єктом. Вам потрібно концептуально відокремити логіку. Ймовірно, так випливає, що код у вашому коді позаду робить багато різних речей. Клас повинен робити одне і лише одне. Спробуйте і подумайте, як ви можете концептуально витягнути існуючу функціональність. Наприклад, скажімо, що у вас є сторінка реєстрації, і ви збираєте інформацію про користувачів. Напевно у вас є кнопка під назвою зареєструватись та подія натискання, пов’язана з цією кнопкою. У цьому випадку ви зберігаєте інформацію про користувача та виконуюте будь-яку обробку, яка вам потрібна. Ви можете створити об’єкт реєстрації для обробки всієї цієї логіки.

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

Якщо ви хотіли чітко дотримуватися шаблону MVP, замість передачі параметрів об'єкту реєстрації, код-позаду реалізував би інтерфейс. Реалізація інтерфейсу, по суті, відображатиме всі об'єкти перегляду (текстове поле тощо) в інтерфейс. наприклад, загальнодоступна рядок FirstName {get {return txtFirstName.Text; }}

Після цього ви можете передати сторінку об’єкту реєстрації

Реєстрація.РегістрUser (це);

І цей метод RegisterUser взяв би інтерфейс як параметр

public bool RegisterUser (користувач IUser) {user.FirstName ...}

публічний інтерфейс IUser {public string FirstName; }

Якщо цей MVP звучить заплутано, просто зосередьтеся на рефакторингу і знайте, що все це полягає в максимальному використанні коду. Немає жодного разу в тому, щоб повторити себе. Це головний принцип DRY .