Цитата из википедии:
> модель данных приложения, > пользовательский интерфейс и > управляющая логика > разделены на три отдельных компонента
Потом под "управляющей логикой" начинают понимать "бизнес-логику", которая вообще говоря — часть модели предметной области.
Это ненормально — делить модель предметной области на "данные приложения" и "управляющую логику", ведь ООП как раз предназначено для того,
чтобы объединить поля и методы в объекты — т.е. сделать прямо противоположное!
Если же бизнес-логика относится к модели данных приложения, то что остается в "управляющей" логике?
Я правильно понимаю, то все это растет из того, что в базе данных хранятся данные, а не объекты (с кодом)?
Мне очень нравится подпись кого-то про то, что любая проблема решается введением дополнительного абстратного слоя.
В данном случае, если мы хотим иметь возможность отображать что-либо на разных устройствах, то достаточно определить интерфейс модели (вместе с бизнес-логикой)
и пусть этим интерфейсом пользуются различные "представления".
AS>Это ненормально — делить модель предметной области на "данные приложения" и "управляющую логику", AS>ведь ООП как раз предназначено для того, чтобы объединить поля и методы в объекты
это какой-то неправильный ООП у вас. радикальная исламская ветвь. некошерно.
данные -- это данные. методы их обработки -- это методы их обработки.
допустим, есть метод -- поиск подстроки. он может работать с разными типами данных. а с этими данными в свою очередь может работать кто-то еще...
ну вот у нас есть IPS. это данные (трафик, который мы снифми, и база сигнатур), бизнес-логика, которая ищет эти сигнатуры в трафике, и web-интерфейс. бизнес логика отвязана и от интерфейса и от данных. сегодня это трафик -- завтра это file uploads, вчера сигнатуры -- сегодня это эвристический двиг.
при этом все строго с "заветами" ООП. в частности, веб-интерфйес сношается только с бизнес-логикой и эта бизнес-логика скрывает он него детали оргранизации входных данных.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
1) MV* — классический пример баззворда: все согласны, что это круто, но каждый лепит MV по-разному.
2) Чуть-чуть истории. Олдскульный MVC — это описание приёмов, что применялись при разработке текстового редактора на смоллтоке-80 Затем о MVC вскользь упомянул Фаулер в Patterns of Enterprise Application Architecture.
Controller Model View Controller (MVC) is one of the most quoted (and most misquoted) patterns around. It started as a framework developed by Trygve Reenskaug for the Smalltalk platform in the late 1970s. Since then it has played an influential role in most UI frameworks and in the thinking about UI design.
И панеслась
3) Всегда находятся пуристы, любящие паттерны больше людей. Образуются странные кучки "за MVC — против <вставить нужное>". Причём характер противопоставления абсолютно шизофреничен: у нас view model? Пишем обёртку к данным и долой биндинги
4) Сама концепция mv* — разделение модели и представления. См п.2 — догадываетесь, откуда все эти "мы включили в модель свойства panel 1 и panel 2"? В большей части примеров модель используется для управления сложным UI. О MV на уровне приложения речь заходит куда реже, несмотря на то, что пользы от неё существенно больше.
5) MV на уровне UI в чистом виде абсолютно нежизнеспособна, т.к. не учитывает особенностей UI-фреймворка. Разновидности наподобие MVVM — бесполезны на уровне приложения, т.к. тащат в контроллеры классы из UI-фреймворка, а на уровне отдельных контролов — это всего лишь описание официальных гадлайнов от производителя фреймворка.
6) MV на уровне приложения — полностью ортогонален используемому UI-фреймворку, т.к. направлен на отделение бизнес-логики от UI приложения. Как можно реализовать
По выделенным жирным ссылкам тоже можно узнать мноого нового
AS>Потом под "управляющей логикой" начинают понимать "бизнес-логику", которая вообще говоря — часть модели предметной области.
Ну, смотря что под предметной областью понимать Если предметную область программы — то да. Если предметную область _заказчика_ — то, с чем он работает — то явно нет AS>Это ненормально — делить модель предметной области на "данные приложения" и "управляющую логику", ведь ООП как раз предназначено для того, AS>чтобы объединить поля и методы в объекты — т.е. сделать прямо противоположное!
Не совсем так. ООП главным образом заточено под создание и переиспользование программных компонентов (с минимальными сложностями при обработке напильником). Собственно, поэтому всякие UI-фреймворки в ООП-языках приживаются как родные, а вот сложные модели — увы
Понимаете в чём штука: ваше приложение — это не вся модель деятельности заказчика, а маааленькая её часть. Соответственно, чтоб не привязывать данные к сиюминутным потребностям (а данные заказчику куда важнее самого распрекрасного кода) код и данные можно (и нужно) разделять. AS>Если же бизнес-логика относится к модели данных приложения, то что остается в "управляющей" логике?
Например, "поведение" вашего приложения — всё, кто не относится напрямую к UI AS>Я правильно понимаю, то все это растет из того, что в базе данных хранятся данные, а не объекты (с кодом)?
Нет (см п2 из многобукв) AS>В данном случае, если мы хотим иметь возможность отображать что-либо на разных устройствах, то достаточно определить интерфейс модели (вместе с бизнес-логикой) AS>и пусть этим интерфейсом пользуются различные "представления".
Поздравляю — вы сейчас описали MV-подход на уровне всего приложения
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Потом под "управляющей логикой" начинают понимать "бизнес-логику", которая вообще говоря — часть модели предметной области. AS>Это ненормально — делить модель предметной области на "данные приложения" и "управляющую логику", ведь ООП как раз предназначено для того, AS>чтобы объединить поля и методы в объекты — т.е. сделать прямо противоположное!
Ничего "противоположного" тут нет: объединение данных и логики одного вида в объекты одновременно является отделением и сокрытием их от данных и логики других видов. Сиречь — инкапсуляцией.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>В данном случае, если мы хотим иметь возможность отображать что-либо на разных устройствах, то достаточно определить интерфейс модели (вместе с бизнес-логикой) AS>и пусть этим интерфейсом пользуются различные "представления".
AS>>В данном случае, если мы хотим иметь возможность отображать что-либо на разных устройствах, то достаточно определить интерфейс модели (вместе с бизнес-логикой) AS>>и пусть этим интерфейсом пользуются различные "представления".
M>Ну да ... это и есть MVC
Здравствуйте, minorlogic, Вы писали:
AS>>В данном случае, если мы хотим иметь возможность отображать что-либо на разных устройствах, то достаточно определить интерфейс модели (вместе с бизнес-логикой) AS>>и пусть этим интерфейсом пользуются различные "представления".
M>Ну да ... это и есть MVC
Мне показалось, что автор имеет в виду отделенный слой бизнес логики, методы которого вызываются из View. Если я прав, то у него может быть такой код:
class CustomerForm : Form { ...
private void btnSaveCustomer_Click(...)
{
Customer customer = (Customer)cbCustomer.SelectedItem;
CustomerService.Save(customer);
UI.ShowSuccess("Customer has been successfully saved.");
}
А это не MVC. Хотя может быть я не правильно понял то, что имел в виду автор.
Зависит от того какую логику автор имеет в виду. Если логика представления View то это контролер из MVC, Если нет то автор не до конца понимает что такое MVC. MVC распологается на слой выше всей бизнес логики , фактически MVC туп до безобразия.
M> MVC распологается на слой выше всей бизнес логики
Это MCCV — у модели один контроллер, у view — другой и Вы почему-то их разделили, хотя в модели про такое разделение не говорится.
Может это Ваши фантазии?
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Цитата из википедии:
>> модель данных приложения, >> пользовательский интерфейс и >> управляющая логика >> разделены на три отдельных компонента
AS>Потом под "управляющей логикой" начинают понимать "бизнес-логику", которая вообще говоря — часть модели предметной области.
Как говорил профессор Преображенский, советские газеты не всегда полезны.
Берём английский вариант статьи:
"Model–View–Controller (MVC) is a software architecture,[1] currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns)."
Всё чётко и ясно.
Если есть время — можете подправить русскую статью, люди вам спасибо скажут.
Здравствуйте, Arsen.Shnurkov, Вы писали:
M>> MVC распологается на слой выше всей бизнес логики
AS>Это MCCV — у модели один контроллер, у view — другой и Вы почему-то их разделили, хотя в модели про такое разделение не говорится. AS>Может это Ваши фантазии?
Я правильно понимаю, то все это растет из того, что в базе данных хранятся данные, а не объекты (с кодом)?
Не расстраивайтесь, этот паттерн никто не понимает. Он слишком долго был мертвым, а воскрешали его не самые лучшие некроманты на примерах "приложение это такая веб страничка, которая показывает содержимое базы данных". Когда начали использовать для чего-то сложнее домашних страничек, мнения разошлись и на данный момент есть десятки реализаций где M, V и C размещены в самых неожиданных местах и комбинациях.
Непонимание только от того что в контролер пытаюстся запихнуть бизнес логику.
А контролер имеет отношение лишь к сложной логике отображения. В простейших случаях MVC контролер вообще не нужен, когда требутся отобразить состояния модели 1 к 1
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, minorlogic, Вы писали:
M>>В простейших случаях MVC контролер вообще не нужен, когда требутся отобразить состояния модели 1 к 1
L>А как тогда view узнает, откуда брать model?
View ничего брать не откуда не должен, модель ему отдаетсяизвне. Это не обязанность вьюхи.
Здравствуйте, minorlogic, Вы писали:
M>>>В простейших случаях MVC контролер вообще не нужен, когда требутся отобразить состояния модели 1 к 1
L>>А как тогда view узнает, откуда брать model?
M>View ничего брать не откуда не должен, модель ему отдаетсяизвне. Это не обязанность вьюхи.
Правильно, это обязанность контроллера, который якобы "не нужен".
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, minorlogic, Вы писали:
M>>>>В простейших случаях MVC контролер вообще не нужен, когда требутся отобразить состояния модели 1 к 1
L>>>А как тогда view узнает, откуда брать model?
M>>View ничего брать не откуда не должен, модель ему отдаетсяизвне. Это не обязанность вьюхи.
L>Правильно, это обязанность контроллера, который якобы "не нужен".
Здравствуйте, minorlogic, Вы писали:
L>>>>А как тогда view узнает, откуда брать model?
M>>>View ничего брать не откуда не должен, модель ему отдаетсяизвне. Это не обязанность вьюхи.
L>>Правильно, это обязанность контроллера, который якобы "не нужен".
M>Не в коем случае. Вы что то путаете.
Здравствуйте, Lloyd, Вы писали:
L>Может быть вы тогда ответите на вопрос: L>
L>А как тогда view узнает, откуда брать model?
L>
Я уже подробно ответил, что вам непонятнов ответе? у view нет ответственности знать о происхождении или уметь доставать модель.
model и view связываются извне логикой приложения.
view может менять модели во время выполнения , модель может менять view во время выполнения. И это все не компетенция MVC компонентов.
Всё так же, как и с прочими паттернами
).
Затем о MVC вскользь 
