Принципи 7 багатошарової моделі

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

Концепція, відома як багатошарова, виникла після того, як клієнт-серверні програми набули буму, пов'язані з ростом Інтернету, тоді як приватні мережі (Інтранет) також стали популярними. Однією з найважливіших цілей є те, що розробка не впливає на роботу, а тим більше запити користувачів у системі, яка постійно використовується.

Так стан справ, наприклад, в масивної землі проекту, де поле техніки, відображення або дигітайзери повинні годувати інформацію; то юридичні аналітики, технічний ГІС і регуляризація повинні обробляти дані, як з боку зовнішніх користувачів існують запити рівня попиту або заявки на онлайн-транзакції.

Давайте подивимося тоді на шари цієї моделі та її принципи.

Розробний шар

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

2. Програми для використання на декількох пристроях.  Необхідно враховувати, що користувачі хочуть отримувати доступ до інформації з настільних пристроїв або різноманітних мобільних телефонів через Інтернет, тому розробники повинні враховувати цей принцип. Незважаючи на те, що непросто передбачити еволюцію добре відомих пристосувань, принаймні слід враховувати спеціальність проекту для цілей подачі та завантаження даних, як у випадку кадастрового процесу, використання GPS-обладнання та КПК з ГІС-додатками / CAD з мінімальними можливостями табличної подачі даних та використанням растрових / векторних даних. Оскільки спеціалізація бізнесу диверсифікована, необхідно знати про розвиток технологій.

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

Шаблон процесу

4 Веб як платформа.  Будь то Інтранет або Інтернет, концепція однакова, шукаючи, щоб робоче середовище користувачів було в мережі, щоб будь-який тип процесів запускався із сервера. Це доповнюється наступним принципом, оскільки метою є забезпечення того, щоб для роботи процесів не потрібні команди з великими ресурсами, хоча необхідно переробити настільні програми.

5 Використання онлайнових програм.  Це є великим викликом для розробників, оскільки цей рівень також включає рівень користувачів, які виконують процеси, які виходять за межі запиту. Такий випадок кадастрового обслуговування, який вимагає використання дискретних файлів, а не лише маніпулювання табличними даними. Для цього обране програмне забезпечення повинно забезпечувати контрольоване середовище управління файлами, керування версіями та процес, відомий як checkout-checkin; Очікується, що API також надасть можливості для деталізації функціональних можливостей та запобігання ускладненню процесів на робочому столі синхронізації.

User Layer

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

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

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