Разделение бизнес-логики от представления в Javascript?

Question

[Test Test]

Приветствую. Хотелось бы поинтересоваться, как вы отделяете бизнес-логику от представления (и работой с DOM) с своих Javascript-приложениях. Меня интересует свои велосипедные решения, а не готовые фреймворки.

Answer 1

[Сергей Протько]

MVC (и развития этих идей: MVVM, MVP, MVA, PAC...)

Идея проста... между двумя слоями вводим третий который изолирует одно от другого. Слоеное лучше бисквита.

p.s. Если вы не знаете как это организовать, лучше на самом деле взять фреймворк или библиотеку, которая организует для вас слой представления и абстрагирует ваш код от него (React например).

Comments

[Test Test]

Спасибо, так и сделаю! Просто хотелось бы уйти от фреймвороков, и написать свой велосипед, в целях понимания и более глубокого изучения.

[Сергей Протько]

Евгений Полевов: толку мало будет на самом деле... просто JS поучить - да. А так...

Но и писать тогда советую сразу на ES6 babel.

[crazyjs]

Сергей Протько зачем фрейворки? не лучше ли взять шаблонизатор хороший, создать "классы" для создания моделей и коллекций - реализовать там нужную логику, ну и добавить промежуточное звено для связывания данных и вьюх. Максимум requireJS использовать ( и то для сборки )

[Сергей Протько]

crazyjs:
1) ну ок, мы возьмем кучку библиотек, напишем связывающий все это бойлерплейт и получим... что бы вы думали, фреймворк. Свой, велосипедный, но родной. Это нормальная практика но переходит к такому подходу стоит не сразу а поработав с существующими фреймворками. 90% что они полностью удовлетворят вашим нуждам, и набраться опыта в плане структуризации приложения можно и т.д.

2) Что бы вы не придумали, у вас всеравно выйдет MVC или какая-либо вариация. Может вы еще пару дополнительных слоев воткнете что бы было удобнее, но суть от этого не меняется.

3) Не думаю что имеет смысл вообще сегодня использовать RequireJS. Года два назад - да. Сейчас есть ES6/7, есть babel, есть полифилы для System.js... лучше это, хоть будет в браузерах когда-нибудь нативно работать. А с HTTP2 можно будет даже не собирать.

4) Велосипедостроение можно поддерживать только если в рамках обучения, или если вы уже попробовали плотно поработать с уже существующими велосипедами.

[crazyjs]

Сергей Протько согласен получим все тот же фреймворк. Но можно избавиться от дублирования кода - например многие используют AngularJS с jQuery, в котором по сути половина функционала angular реализована - deferred,
манипуляция DOM( хоть минимальная но все в angular тоже есть), работа c ajax и т.д. + добавляют еще и другие фреймворк, в которых тоже часть этого уже есть ( можно конечно настроить build любого фреймворка и выбросить дублирование, но мало кто так делает )

[Сергей Протько]

crazyjs: ну начнем с того что:

- deferred реализовано на уровне стандартной библиотеки JS уже в хроме. Так что... И да, angular умеет работать с оным.
- jQuery можно собрать выкинув все ненужные модули.
- Не все работают с jQuery + angular. Я вот не использую jQuery вообще (только в ооочень редких случаях когда внутри директивы какой-нибудь плагин для оного есть).

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

Answer 2

[Mikhail Osher]

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

Answer 3

[smanioso]

Если не нравятся монструозные фреймворки, то можно посмотреть вот это:
https://andywalpole.me/#!/blog/142134/2015-the-end...
https://github.com/facebook/react/wiki/Complementa...

Answer 4

[Константин Китманов]

Принцип единственной ответственности рулит. Остальное — детали.