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

Так вот.
Вот хоть убейте, не могу понять, что такое класс-сущность, граничный класс и т.п.

Можно на конкретных примерах пояснить?

Буду очень благодарен.
Спасибо.

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

Так вот.
Вот хоть убейте, не могу понять, что такое класс-сущность, граничный класс и т.п.

Можно на конкретных примерах пояснить?
Буду очень благодарен.
Спасибо.

В подходе BCE (Boundary-Controller-Entity):

Entity (Класс-сущность) - отвечает за хранение информации по объекту-сущности, например такому, как "Заказ" и содержит методы, соответствующие его бизнес-логике, типа добавить строку заказа, завершить заказ и т.д.

Boundary (пограничный класс) - отвечает за организацию взаимодействия с субъектом (actor). В оконных приложениях это грубо говоря, класс окна.

Controller (управляющий класс) - отвечает за передачу запросов от Boundary нужным классам Entity и возвращает ему результаты. Грубо говоря, Контроллер заказа "дёргает" методы Заказа, и получив ответ, обновляет Окно (+ может делать множество других операций,  связанных с другими сущностями ПрОбл и Приложения, типа логирования). Т.е. он отвечает в том числе за Логику Приложения (в отличие от Бизнес-Логики), если нет отдельного слоя Логики Приложений, например, отсечённого от Контроллера Сервисным слоем.

В настольном приложении все классы реализуются в компоненты, находящиеся на данной машине. В клиент-серверных приложениях если клиент толстый, то B и C находится на клиенте, а E - скорее всего на сервере. Если клиент тонкий, то в принципе вся связка BCE находится на серверной стороне, причём эти классы могут быть распределены по разным физическим серверам (по крайней мере BC отдельно от E).

Вот ещё примерчик для неоконного приложения, в котором граничными классами выступают устройства чтения карты и клавиатура.

Подробнее об этом можно почитать, например, у Мацящека.

Вообще мне этот подход кажется довольно спорным, т.к. имхо аналитик не должен заниматься проектированием системы, если эти функции разделены по людям, т.к. иначе потом придёт архитектор и окажется, что он всё реализует иначе, исходя из неФ-требований, и работа анлитика идёт коту под хвост.

Андрей. Ну какие еще вам примеры нужны.
Класс-сущность - это нечто относящееся к предметной области, несто, что возможно будете хранить в долговременной памяти. Например: Лекции, Тесты, Студенты, Преподаватели, Персона, Дисциплина, и т.п. - Обычно для каждого такого класса создают таблицу в БД.
Граничные классы располагаются на ГРАНИЦЕ системы и внешней среды. Это формы, отчеты, интерфейсы к аппаратуре, другим системам
У вас ООП было? В чем программировали? Наверняка формы делали - а что такое форма, как не класс с определенными характеристиками, событиями и прочее.

У вас ООП было? В чем программировали? Наверняка формы делали - а что такое форма, как не класс с определенными характеристиками, событиями и прочее.

Ну, Delphi было, но мало
Сейчас PHP5 используем на работе.
Так. Ну я кажется понял

Стоп, Вы студент, или работник? Ничего не понял?
Но все равно, даже в РНР5 можно увидеть эти граничные классы - совсем несложно создать объект который формирует часть HTML страницы, например форму авторизации.
Так вообщем-то и сделано в cms-ках многих

Стоп, Вы студент, или работник? Ничего не понял?
Но все равно, даже в РНР5 можно увидеть эти граничные классы - совсем несложно создать объект который формирует часть HTML страницы, например форму авторизации.
Так вообщем-то и сделано в cms-ках многих

Я и тот и другой
Учусь на пятом курсе, пишу диплом. И работаю. В данный момент занимаюсь MySQL

А все это затеял для диплома.

Код: [Выделить]

<?php

class UserForm
{
public name;
public lastname;
...
public submit;

public function __construct()
{
$this->name = "<input type=text name=name>";
$this->lastname = "<input type=text name=lastname>";
...
$this->submit = "<input type=submit value='Register'>";
}
public function showForm()
{
echo "<table>";
echo "<tr><td>Name:</td>"; echo "<td>".$this->name."</td>"; echo "</tr>";
echo "<tr><td>Last Name:</td>"; echo "<td>".$this->lastname."</td>"; echo "</tr>";
echo "<tr><td colspan=2>.$this->submit."</td>"; echo "</tr>";
echo "</table>";
}
}

?>

Это что-то типа такого класса, что ли? %)

ну да

А в этом что-то есть. Никогда как-то не сталкивался с таким...
Только вот думаю, что для малокого количества людей в разработке - это нормально, где программист является и дизайнером и верстальщиком...
А вот например в большой группе людей, например верстальщик. который ничего не смыслит в программировании - будет трудно понятно что здесь и как.
Не лучше ли просто использовать какие-то темплейты, которые будут вставляться в те места, которые надо?

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

Код: [Выделить]

<?php

class User
{
public name;
public lastname;
...

public function __construct($name, $lastname, ...)
{
$this->name = $name;
$this->lastname = $lastname;
...
}

public function getName()
{
return this->name;
}
...
...
...
}

?>

Я иду в правильном направлении?

Да, конечно. Класс-сущность отображает предметную область.

Насчет верстальщика и программера.

Что такое верстальщик - это все-таки не совсем просто дизайнер. Просто дизайнер - это фактически художник, который рисует вам дизайн в Photoshop к примеру. А верстальщик уже идею дизайнера воплощает в шаблон. А шаблон будет использовать html-коды - это уже разметка, это уже программа, css-стили, а это тоже требует ясного представления о сути проблемы.

Классическая архитектура приложения: логика представления(1 слой), бизнес-логика или программная логика работы системы(2 слой), логика данных скажем(или 3 уровень хранение данных).

Посмотрим как это зачастую реализуется например в Delphi:
Скажем есть база данных.
В приложении мы делаем: уровень подключение к БД - типа DataBaseConnection Transaction
Далее формируем DataSet - класс для доступа к набору данных и манипуляции с ним
DataSource - класс связывающийся с DaTaSet и фактически преобразующий сущности БД в сущности программы и не посредственно соединяется с элементами DataControl - поля, списки, гриды и тп.

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

Так. Ну вот с граничным классом и классом сущностью я разобрался. Остался третий класс - контроллер, да?
Это например будет класс, где есть куча методов, которые работают с классом User.
Например метод RegisterUser или UpdateUserInfo, так?

Необязательно только с юзером, В моем примере, который я привел ранее - это классы скажем DatBaseConnection, т.е. классы которые исполняют какие-то общие действия. Например классы без состояния.

Скажем в коде рнр это мог бы быть например класс доступа к БД (соединение, выбор бд, выполнение запроса, возвращение данных, закрытие соединения с сервером) Примерно так.
Т.е. например у вас есть ссылка - показать список преподавателей. Каков цикл действия может быть? Вызов класса отвечающего за соединение БД, вызов класса выполняющего запрос и подгтовку данных, вызов класса формирующего шаблон отображения. Т.е. классы управляющие (control) работой других, помогающие другим и прочее.
Все это связано с архитектурой или моделью MVC. В вашем случае, может конечно будет так, что никакого реального деления классов и не будет, однако такой подход позволяет делать повторно используемый код и т.п.

Ну посмотрите на библиотеку PEAR или шаблоны SMARTY или FASTTEMPLATE... Надеюсь объяснил? Если нет попробуйте почитать здесь http://www.intuit.ru/department/pl/umlbasics/5/

Да, спасибо большое за разъяснения. теперь мне все понятно. Впринципе я что-то такое и думал в самом начале, просто наверно не мог сформулировать.
Спасибо большое.

На здоровье, Андрей.
Очень рад, если сумел что-то объяснить и чем-то помочь.
Надеюсь, выполнив свой проект, Вы:
1. Опубликуете его, как пример для обсуждения и подражания
2. Не потеряете контакта с нашим ресурсом
3. Научите нас в будущем чему-то интересному