Основные парадигмы/концепции построения архитектуры для web и приложений?

Question

[bubbleboom]

За неимением большого опыта, (менее года) но большой любознательности в голове образовалась каша.
Собственно, интересует следующий момент. Какие есть основные концепции построения архитектуры приложений?

Например, имеется задача разработать классическое приложение для работы с БД (CRUD)
Т.е. простым языком – сайт, где можно: сделать новость, отредактировать, что-то апдейтнуть или удалить.
Но, у меня стоит особняком один важный момент. Хочу что-бы это приложение в перспективе могло быть нативным гибридным для мобильных платформ. Таких как OS или Android.
Т.е. простым языком – нативное гибридное приложение, для каждой из платформ не важно для какой платформы, дергающее API и имеющее 100% функционал сайта.

• Общую архитектуру для приложения выбираю MVC. (Потому, что мне так удобно и понятно)
  
• А для важного момента выбираю архитектуру REST

Т.е. совмещаю 2 концепции, но реализую разные вьюхи. Код моделей собсвенно единый.

Спрашивается, а не дурак я? Может под обозначенные требования имеется архитектура уже проверенная временем. А я просто не знаю. Возможно мне нужна книга, где приводятся в пример удачные концепции и в ней я найду более правильный и/или технически проще реализуемый вариант для моей задачи. Или ты, человек сложивший миллионы строк кода в единый организм - откроешь мне глаза. В общем помогите, други. :)
P.S. Поставленная задача академического плана.
Update 31.07.15 (11:30)
1) Благодаря острому, словно бритва "джилет фьюжен макс повер проГлайд", ответу от нашего брата index0h, исправил формулировку вопроса указав правильный тип приложения.

Comments

[bubbleboom]

copal: Это ближе к делу. Как делают? Поясните чуть-чуть детальнее. Пожалуйста. Мне интересно как Вы, реализуете эту задачу на примере простого CRUD приложения. Так-же, если последует ответ, интересно откуда почерпнули знания. Возможно будет ссылка на хорошую статью, книгу или ваши мысли с блога. Я правда ищу знания, ввиду того, что мало опыта в с сфере IT. Менее года. И готов прислушаться когда мне говорят, что так не делают. Со всем уважением жду вашего ответа.

Answer 1

[bubbleboom]

В общем всем спасибо! Для тех кого заинтересовал вопрос советую почитать статью: habrahabr.ru/post/260769
Думаю, глубже копать дальше только экскаватором. Статья отлично раскрывает мой вопрос, а главное ожидание чего-то нового.

Answer 2

[evnuh]

Всё верно придумали.
По идее, у вас должно быть ядро без отображения, которое имеет вход и выход. Входом у вас соответсвенно являются и в случае с сайтом, и в случае с API для мобильных - HTTP запросы типа GET и POST, PUT и т.д., тут вообще они не отличаются. А на выходе вы должны данные либо кидать для рендеринга в HTML, либо кидать их для рендеринга в JSON или в любой другой сериализатор, который будет понятен нативным приложениям на телефонах.

Comments

[bubbleboom]

Чуть выше, мне оставили комментарий пересмотреть свои взгляды. К сожалению без каких либо деталей. Что скажете evnuh? Может мы с Вами сможем найти более функционально/красивое решение на примере простого как палка CRUD - приложения.

[evnuh]

bubbleboom: побольше слушайте. У вас все хорошо, вы главное поменьше думайте над архитектурой, а то часто это приводит к ООП головного мозга.

[bubbleboom]

evnuh: Да ведь задача изначально проста, как палка-копалка. Вся соль в архитектуре. И вопрос был по архитектуре. Мне будет не лень (а, патаму-шта задача академ. характера:) реализовать несколько решений, кроме того самого, что есть в моем вопросе. Может есть варианты без API или <попробуй эту архитектуру>. Т.е. коллективный опыт для упрощение объявленной архитектуры (внутренний голос:-"Да, сделай это проще, John!"). Собственно цель вопроса была именно такая. С уважением, bubbleboom

Answer 3

[index0h]

нативное приложение, не важно для какой платформы

оксюморон))

Вы правы, у вас каша. То, что вы хотите REST сервис - это серверная часть, ее делать для того же Android смысла особого нет потому, что на моб приложение будет выступать клиентом. Если же хотите использовать БД на клиенте - REST будет лишним, на порядки проще использовать ORM какую-то.

Comments

[bubbleboom]

Имел ввиду, как нативное клиент-приложение. Да и из вопроса, это понятно. К сожалению не разделяю Ваш сарказм. Но, спасибо за красивое словечко. Однако, мне все еще интересно, почему нет особого смысла. Может объясните попроще с аргументами в рамах самого вопроса. А, index0h ?

[bubbleboom]

Возможно за имением нулевого опыта в мобильной разработке выразился не корректно. Правильно будет говорить – гибридное приложение.

[index0h]

@bubbleboom

> К сожалению не разделяю Ваш сарказм.
"Нейтивное приложение" означает: приложение, созданное в экосистеме конкретной ОС, согласно принятых в ней норм. Вы же хотите сделать нейтивное для всех ОС, чего быть не может. Кроссплатформенное - да, можно, но не нейтивное.
Это нейтивные: iOS - Swift | Android - Java | WinPhone - C#.

> Однако, мне все еще интересно, почему нет особого смысла.
Простыми словами: вам нужно проверить, есть ли дома в шкафу книга "Енеїда" Котляревського.

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

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

[index0h]

> Правильно будет говорить – гибридное приложение.
До гибридных стоит еще дорости. Это уже распределенные системы, где основным затыком является система синхронизации данных, а именно определение актуального источника данных, на основе самих этих данных.

[bubbleboom]

Я руководствовался статьей: www.ibm.com/developerworks/ru/library/x-mashups
И у меня нет, более подходящего названия типа, для обозначенного моб. приложения из вопроса. А у Вас, index0h?

[bubbleboom]

Я сделаю апдейт вопроса, если Вы, скажете как обозначить тип. Что касается формулировки "не важно для какой платформы" – имел ввиду перечисление платформ, не обобщение. Но всю вину беру на себя, мой вопрос и мне положено было извиниться уже с первых строк вопроса.

[index0h]

bubbleboom
Я себя уже прям деспотом чувствую))
>> И у меня нет, более подходящего названия типа
Кроссплатофрменное приложение / Кросскомпилируемое приложение

Посмотрите apache cordova.

Answer 4

[Tlito]

основные концепции:
1. Ядро с возможностью расширения.
С помощью доп модулей или плагинов ваше приложение должно легко расширяться вами при разработке

2. АПИ-функции для разработки новых функций или модулей.
чтобы ваше приложение правильно расширялось, и вместе с тем было безопасно, нужно сделать базовые функции, которыеми будут пользоваться модули

3. функции ядра или модулей должны проверяться отдельно при разработке.

4. ну и если вы опенсорс-разработчик, то весь код должен быть документирован, комментирован

Comments

[bubbleboom]

а, что касается текущей задачи? Чуть ближе к делу :)

Answer 5

[CapeRatel]

Оу оу. Как человек переживший в недавним времени вашу ситуацию, стаж, и вопросы, советую вам много делать и поменьше думать. Сомневаюсь что с таким стажем вы способны написать хорошо все аспекты описания вопроса.

Мыслите правильно.

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

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

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

У меня все

Comments

[bubbleboom]

Да вроде О_о из описания понятно, что проект академического плана. (учусь ставить себе задачи и их реализовывать). Да и задача изначально проста, как палка-копалка. Вся соль в архитектуре. И вопрос был по архитектуре. Мне будет не лень реализовать несколько решений, кроме того самого, что есть в моем вопросе. :)
=> Я на крудил проект, теперь хочу выгружать в мобилу и на сайт. Как это сделать красиво и тех.правильно, кроме варианта из вопроса. Может есть варианты без API или <попробуй эту архитектуру>. Собсвенно цель вопроса была такая. С уважением, к Вам.

[CapeRatel]

bubbleboom: я думаю что ваши рассуждение верны для академ задачи. Делайте рест это востребовано и полезно