Что меня действительно радует, так это отсутствие профессионалов в рядах этих запрещающих все и вся граждан. Иначе их инициативы имели бы шансы на успех. А так — сделать нормально не смогут, да и большую часть выделенных средств попилят, в итоге получим поделку, которая только делает вид, что работает )))
Насчет сборки решения и публикации пакетов — мы поступили несколько иначе — подняли два билд-сервера.
На первом continious build для решения, на втором — сборка и публикация пакетов в корпоративную галерею.
Плюс у разработчиков есть скрипт для локальной сборки пакетов для тестирования без публикации.
Для того, чтобы не заморачиваться с формированием файла спецификаций, основную информацию мы собираем из атрибутов сборки (AssemblyCompany, AssemblyProduct, AssemblyVersion и т.д.), а зависимости — из packages.config и файла проекта (ProjectReferences).
Версия пакета формируется с использованием Major и Minor версии, в качестве Build используется номер чейнджсета в локальном хранилище кода. Если пакет собирается для отладки, то добавляется Revision, равный номеру дня в месяце + количество секунд от полуночи поделенное на 4. Таким образом пакет в релизе имеет версию, например 1.5.2608, в отладке 1.5.2608.2721276, причем после завершения отладки и чекина, релизный пакет имеет версию, например 1.5.2609. Это упрощает отладку пакета в прикладном решении, так как не нужно руками откатывать версию пакета — после чекина достаточно просто сделать update.
Перед публикацией мы запрашиваем список пакетов из галереи и отсекаем существующие дабы не тормозить на попытках опубликовать пакет, который уже присутствует на сервере. Это помогает нам не публиковать отладочные пакеты в общую галерею и, вместе с тем, позволяет нормально отлаживать пакеты в прикладном решении.
На текущий момент для сборки и публикации пакетов достаточно вызвать билд из веб-интерфейса билд-сервера, что сильно экономит время.
Начал отвечать про галерею, потом посмотрел про UAC и поменял коммент.
Насчет галереи — развернули собственную, довольно удобно при модульной разработке с учетом того что модули могут писать и партнеры.
Ну для начала, скорее всего, я бы переименовал organisation в organization, а в качестве клиентского фреймворка выбрал бы ExtJs.
Имхо бизнес-логики тут вообще никакой нет. На представленных видео описан процесс создания пользователя, роли, профиля, счета (если я правильно понял смысл слова Account) и привязки роли к пользователю через m2m UserRole.
Если бы подобный механизм делал я, то я бы создал домен-сервисы для каждой значимой сущности (Role, User, Profile, Account). Данные сервисы должны иметь функционал по получению данных, обработке, валидации и сохранению. UserRole я бы не выделял, так как смапить m2m через отдельную табличку можно без выделения отдельной сущности для этой таблицы и редакторов данной сущности. После отделил бы логику от представления — в контролерах исключительно базовая валидация поступающих в параметрах запроса данных, проброска проверенных данных в домен-сервис для обработки, мапинг результата работы домен сервиса в ответ для клиента (например json).
Во вьюшках описал бы необходимые контролы + выделил бы отдельный слой на клиенте, отвечающий за взаимодействие клиентской вьюхи и серверного контроллера для получения и отправки данных. Редактор UserRole я бы выпилил, но добавил бы грид со списком привязанных ролей в форму редактирования пользователя.
После формирования вьюшек для сущностей, я бы выделил, 2 основных панели представления — условные «таб» и «окно» + логика показа необходимых редакторов сущностей для них. «Таб» отвечает за открытие вьюшек в текущем окне, «Окно» — в новом (используется в основном для выбора существующих элементов).
Для небольших приложений с небольшой предметной областью, видимо, проблемы то и нету. Но для приложений, где доменная модель состоит из сотен таблиц, проблема очень даже есть.
Выделяется слой Domain Services, который замыкает на себя бизнес-логику. При этом домен-сервисы могут переиспользоваться не только в рамках одного проекта, но и в нескольких проектах (при модульной архитектуре). При использовании, например, .Net Framework одни и те же домен-сервисы могут использоваться в проектах Asp.Net Mvc, Silverlight, WPF.
При этом контроллеры служат исключительно для связи с вьюшками
Например, почему бы не использовать навороченную логику грида с сортировкой, фильтрацией и другими плюшками для выбора значений. Своего рода продвинутый комбобокс, только на отдельной странице.
Для этого выделяется компонент «MySuperMegaGrid», взаимодействующий с сервером по заранее определенному контракту. Например ExtJs GridPanel — настраиваете для него хранилище и правила получения данных с сервера. Потом переиспользуете в разных представлениях один и тот же компонент.
Ну судя по заголовку окна «Пополнение кредитной картой» я предполагаю что пользователь уже зарегистрирован в системе (так как пополнять несуществующий счет, наверное, смысла нет), так что email пользователя уже есть. Если же происходит покупка новым пользователем, то поле e-mail можно сделать опциональным и в случае его отсутствия показывать по завершении покупки параметры заказа и персональную ссылку на скачивание книжки. Еще можно кнопку сделать «Отправить параметры заказа на EMail».
Мне кажется, что наименование банка лишнее.
Вбивать наименование «Объединенный Офигенный Великодержавный Банк Всея Руси Вообще и Москвы В Частности», а они очень любят себя именовать подобным образом, не сильно удобно.
Номера карты, CV2, Expires и Holder — достаточно
Кстати, насчет багов — при открытии двух списков они всегда в стартовой позиции (слева, сверху).
Сам планирую начать изучать Java, так как .NET уже поднадоел. Ваши исходники, думаю, мне помогут.
Успехов вам.
Насчет сборки решения и публикации пакетов — мы поступили несколько иначе — подняли два билд-сервера.
На первом continious build для решения, на втором — сборка и публикация пакетов в корпоративную галерею.
Плюс у разработчиков есть скрипт для локальной сборки пакетов для тестирования без публикации.
Для того, чтобы не заморачиваться с формированием файла спецификаций, основную информацию мы собираем из атрибутов сборки (AssemblyCompany, AssemblyProduct, AssemblyVersion и т.д.), а зависимости — из packages.config и файла проекта (ProjectReferences).
Версия пакета формируется с использованием Major и Minor версии, в качестве Build используется номер чейнджсета в локальном хранилище кода. Если пакет собирается для отладки, то добавляется Revision, равный номеру дня в месяце + количество секунд от полуночи поделенное на 4. Таким образом пакет в релизе имеет версию, например 1.5.2608, в отладке 1.5.2608.2721276, причем после завершения отладки и чекина, релизный пакет имеет версию, например 1.5.2609. Это упрощает отладку пакета в прикладном решении, так как не нужно руками откатывать версию пакета — после чекина достаточно просто сделать update.
Перед публикацией мы запрашиваем список пакетов из галереи и отсекаем существующие дабы не тормозить на попытках опубликовать пакет, который уже присутствует на сервере. Это помогает нам не публиковать отладочные пакеты в общую галерею и, вместе с тем, позволяет нормально отлаживать пакеты в прикладном решении.
На текущий момент для сборки и публикации пакетов достаточно вызвать билд из веб-интерфейса билд-сервера, что сильно экономит время.
Насчет галереи — развернули собственную, довольно удобно при модульной разработке с учетом того что модули могут писать и партнеры.
Имхо бизнес-логики тут вообще никакой нет. На представленных видео описан процесс создания пользователя, роли, профиля, счета (если я правильно понял смысл слова Account) и привязки роли к пользователю через m2m UserRole.
Если бы подобный механизм делал я, то я бы создал домен-сервисы для каждой значимой сущности (Role, User, Profile, Account). Данные сервисы должны иметь функционал по получению данных, обработке, валидации и сохранению. UserRole я бы не выделял, так как смапить m2m через отдельную табличку можно без выделения отдельной сущности для этой таблицы и редакторов данной сущности. После отделил бы логику от представления — в контролерах исключительно базовая валидация поступающих в параметрах запроса данных, проброска проверенных данных в домен-сервис для обработки, мапинг результата работы домен сервиса в ответ для клиента (например json).
Во вьюшках описал бы необходимые контролы + выделил бы отдельный слой на клиенте, отвечающий за взаимодействие клиентской вьюхи и серверного контроллера для получения и отправки данных. Редактор UserRole я бы выпилил, но добавил бы грид со списком привязанных ролей в форму редактирования пользователя.
После формирования вьюшек для сущностей, я бы выделил, 2 основных панели представления — условные «таб» и «окно» + логика показа необходимых редакторов сущностей для них. «Таб» отвечает за открытие вьюшек в текущем окне, «Окно» — в новом (используется в основном для выбора существующих элементов).
Как-то так…
Выделяется слой Domain Services, который замыкает на себя бизнес-логику. При этом домен-сервисы могут переиспользоваться не только в рамках одного проекта, но и в нескольких проектах (при модульной архитектуре). При использовании, например, .Net Framework одни и те же домен-сервисы могут использоваться в проектах Asp.Net Mvc, Silverlight, WPF.
При этом контроллеры служат исключительно для связи с вьюшками
Для этого выделяется компонент «MySuperMegaGrid», взаимодействующий с сервером по заранее определенному контракту. Например ExtJs GridPanel — настраиваете для него хранилище и правила получения данных с сервера. Потом переиспользуете в разных представлениях один и тот же компонент.
Как-то так.
Я так думаю что на телефоне придется скролить оченно долго.
Вбивать наименование «Объединенный Офигенный Великодержавный Банк Всея Руси Вообще и Москвы В Частности», а они очень любят себя именовать подобным образом, не сильно удобно.
Номера карты, CV2, Expires и Holder — достаточно
Fences — да, тоже вполне себе ничего
Сам планирую начать изучать Java, так как .NET уже поднадоел. Ваши исходники, думаю, мне помогут.
Успехов вам.