Форум 'Архитектура программного обеспечения' на RSDN.RU

ORM ?

Tue, 09 Mar 2010 22:42:24 GMT

Коллеги.

Поделитесь познаниями по следующему вопросу.

У нас есть реляционная БД, в которой структура таблиц соответствует бизнес-объектам(сущностям). Чтение-сохранение реализовано в виде хранимок БД, фактически для каждой сущности реализованы процедуры read-write. Там же сейчас реализована бизнес-логика работы приложения.
Есть задача с минимальными переделками вынести часть функциональности программы в Application Server на Java и обеспечить представление сущностей в Object-структуре (нарисовать xsd-шки со структурой объектов и уметь мэппить их на базу).

Проблема.
Разрулить переход от ссылочной модели представления данных к объектной. (не знаю поможет ли нам здесь ORM, т.к. читать-писать надо продолжать через хранимки).

Пример. Есть клиент, у него есть договора, у которых в свою очередь есть счета, схемы тарифов и.т.п. У каждой сущности свой набор атрибутов.
Client
Id
Name
ValidDate
...
Pact10
PactNumber
PactDate
TariffPlan
Account
..

В БД это все само собой хранилось в виде foreign key и при необходимости вытаскивалось чтением из таблиц.
В Java есть желание сделать поуровневое чтение объекта — т.е. сначала читаем первый уровень вложенности объекта (Client). Если идет обращение ко второму уровню вложенности (например, к Pact), а структура Pact не начитана, начитать ее из БД. И так далее — по мере обращения к полям начитывать соответствующие структуры.
Также в каждой структуре хранить флаг валидности объекта — если данные допустим объекта-договора изменились — перед выполнением какого-либо действия надо сказать, чтобы сохранил персистенцию в базу.

Самое главное, чего не охота делать — дорисовывать указанную функциональность в методы каждого класса вручную.
Сейчас пользуюсь JAXB'ом для генерации структуры классов описанной в XSD, но очень хочется, чтобы они сразу генерились с "умными" геттерами/сеттерами.

Может есть какие шаблоны/методики/технологии на этот счет?

P.S. С Явой начал дружить совсем недолго, поэтому еще могу не сильно ориентироваться в инструментарии — если подскажите в каком направлении двигаться, с меня пиво

... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>

Целесообразность использования DI-фреймворков

Sun, 07 Mar 2010 16:12:50 GMT

Существует такой популярный паттерн — инъекция зависимости (DI) Реализация данного паттерна традиционно предполагает использование того или иного IoC контейнера. Рассмотрим пример:

class Bar 
{
    public Bar(string message)
    {
        Message = message;
    }
    public string Message { get; private set;}
}

interface IBarProvider
{ 
    Bar GetBar(); 
}

class HelloBarProvider:IBarProvider
{
    public Bar GetBar()
    {
        return new Bar("Hello");
    }
}

class Foo
{
    public Foo(IBarProvider barProvider)
    {
        _barProvider = barProvider;
    }
    
    public Execute()
    {
        Console.WriteLine(_barProvider.GetBar().Message);
    }
    
    IBarProvider _barProvider;
}

Задача IoC контейнера в данном случае — это определить зависимость между классом "Foo" и классом "HelloBarProvider" (поскольку эти классы друг о друге вообще не знают). Например, при использовании Spring конфигурация контейнера будет выглядеть как:

Вариант 1:

<object id="barProvider" type="Namespace.HelloBarProvider, assembly" />
<object id="foo" type="Namespace.Foo, assembly">
    <constructor-arg ref="barProvider" />
</object>

Без использования DI-фреймворка аналогичный код можно было бы написать слудующим образом:

Вариант 2:

class DIContainer
{
    public DIContainer()
    {
        BarProvider = new HelloBarProvider();
        Foo = new Foo(BarProvider);
    }
    public IBarProvider BarProvider { get; set; }
    public Foo Foo { get; set; }
}

Вариант 2 имеет следующие преимущества:
1) Он проще, поскольку не требуется знания DI-фреймворка и специфики его использования
2) Он значительно надежней, так как корректность кода проверяется компилятором. Например, если мы добавим в HelloBarProvider еще один конструктор и забедем внести соответствующие изменения в IoC контейнер, то в первом случае мы это увидим только в run-time с трудночитаемым текстом исключения, а во втором нам об ошибке сразу сообщит компилятор.
3) Он значительно легче в поддержке, так как можно использовать стандартные средства рефакторинга кода. Например, если мы решим переименовать IBarProvider, то все соответствующие изменения будут автоматически отражены в коде контейнера
4) Вариант 2 легче писать, так как мы имеем полную поддержку со стороны IDE в виде intellisence, code completion и пр.
5) Он гибче, так как позволяет реализовать произвольную сложную логику определения зависимостей.
6) Вариант 1 нарушает инкапсуляцию, так как выставляет наружу "кишки" приложения.
7) Вариант 2 можно отлаживать по шагам.
8) В случае ошибок мы имеем удобоваримые исключения с нормальным call-stack
9) Вариант 2 обладает на порядок большим количеством возможностей для декомпозиции сложной логики, чем XML
10) Вариант 1 нарушает принцип KISS

Тем не менее, на практике как правило используют первый вариант, и я хотел бы разобраться в причинах. Предвижу следующие ответы:

1) "Вариант 1 позволяет гибко конфигурировать приложение." — Задача определения зависимостей между типами и задача конфигурирования приложения — это две совершенно разные задачи и при попытке их смешать мы автоматически нарушаем SRP, что влечет за собой кучу проблем.
2) "Вариант 1 более декларативен" — Ну да, и дальше то что? Какие мы получаем благодаря этому преимущества? (про недостатки я писал выше)
3) "Вариант 1 — это не только XML, есть фреймворки с fluent-interface" — да, такие фреймворки являются меньшим злом, так как они лишены части недостатков. Но тем не менее в чем заключается их смысл? Какие дополнительные возможности они дают?

Что еще?

PowerDesigner brunch

Fri, 05 Mar 2010 13:31:12 GMT

Юзаю PowerDesigner 15.0.
Столкнулся с проблемой. Создаю бранч. Он цепляет последнюю версию из базового бранча, например, 2, и начинает вести внутри себя нумерацию типа 2.1.1, 2.1.2 и т.п.. В базовом бранче создаю версию 3. Каким образом мне зацепить её в дочернем бранче, чтобы можно было вести такую же ветку 3.1.1, 3.1.2 и т.п.?

Как правильно? Совместное использование данных?

Wed, 03 Mar 2010 16:38:23 GMT

Друзья, доброго времени суток!
Прошу совета вот в каком вопросе:
Есть у меня в проекте один объект, который выкачивает данные из Ini-файла, назовем его Config. Инишник содержит настройки для 4х объектов проекта, настройки разделены по "секциям". Вышеописанные четыре объекта относятся к разным "слоям" приложения — два к сетевому уровню, два к гуям и ничего друг о друге не знают.
Те объекты, что относятся к сетевому уровню создаются объектом-контроллером сетевого слоя. Гуевые объекты создаются контроллером слоя отображения.

Алгоритм работы приложения выглядит так:

Запуск приложения
Шаг 1 — Создание объекта Config, считывание информации из инишника
Шаг 2 — Создание контроллера сетевого слоя
Шаг 2.1 — Создание первого объекта сетевого слоя (приемника)
Шаг 2.2 — Создание второго объекта сетевого слоя (передатчика)
Шаг 3 — Создание контроллера слоя отображения
Шаг 3.1 — Создание первого объекта слоя отображения (диалога входа в систему)
Шаг 3.2 — Создание второга объекта слоя отображения (диалога настроек системы)
Шаг 4 — Начало работы

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

Сам рассматриваю следующие варианты:
1. Дать указатель на Config контроллеру сетевого слоя и контроллеру слоя отображения, после чего контроллеры выбирают данные из конфига и передают уже только необходимую информацию своим объектам.
2. Передавать указатель на конфиг всем четырем объектам. Объекты сами выбирают необходимую информацию из конфига.
3. Сделать Config глобальным и позволить объектам работать с ним напрямую

Немного об объекте Config — он считывает информацию из ини-файла во внутреннее хранилище, все манипуляции происходят с копией данных в этом самом внутреннем хранилище. При завершении внутренняя информация выгружается на диск.

Пишу на C++ с MFC.

Буду рад любым советам.
Спасибо.

TDD и проектирование

Wed, 03 Mar 2010 10:05:46 GMT

Здравствуйте, уважаемые коллеги

Хочу внедрять практику TDD, т.е. что бы разработка была через тестирование.
Плюсы unit tests очевидны — проект более легко сопровождаем, если есть unit tests.

Основной посыл TDD — вначале тест и говнокод — потом проектирование и рефакторинг.
Т.е. программист P1 начинает реализовывать задачу T1, то у него нет никаких диаграмм классов.
Классы и правильный дизайн будет на выходе после рефакторинга. Все просто замечательно.
Но, а как же работа в команде? Если P1 не реализовал метод сохранение объекта O1 а этот метод нужен программисту P2?
Понятно, что программист P2 может сделать фиктивный метод, но ему нужен хотя бы прототип этого метода — сигнатура метода,
типы генерируемых исключений и т.д. Но методология TDD не позволяет программисту P1 распылять свои усилия и пока он не решит свою текущую проблему, он преступить к методу сохранения объекта O1 не может. Как быть? Понятно, что нужен некоторый интерфейс, что бы программист P2 не дожидался реализации метода сохранения объекта O1, а мог бы использовать фиктивную реализацию этого метода.

Вопрос в том, что концепция TDD, как бы не совсем приветствует проектирование наперед, но в то же время какой-то интерфейс должен быть, т.е. в приложении должны быть выделены слои и должен быть интерфейс? Меня не особо интересует как бы теория, нужны больше примеры из реальной командной разработки ( у К. Бека книга хороша, но нет примера командной разработки).

Архитектура многопоточных приложений

Sun, 28 Feb 2010 16:07:46 GMT

Здравствуйте!
Можете подсказать, какую-нибудь литературу, сайты и т.п. по основным принципам проектирование многопоточных систем? В приложении, разработкой которого я занимаюсь, довольно много объектов со своим потоком выполнения; проблема в том что несмотря на довольно большое время тестирования приложения всё равно периодически вылазят баги с какой-то взаимоблокировкой, которая была всегда, но по какой-то причине до этого себя не проявляла. Хотелось бы узнать, как такие проблемы решаются обычно — какие-нибудь паттерны и т.п.

Заранее спасибо за помощь.

Посоветуйте паттерн(?)

Fri, 26 Feb 2010 09:54:43 GMT

Есть некая сущность, называемая юнит (Unit), состоящая из нескольких пакетов (Package), каждый из которых состоит из нескольких групп (Group), каждая из которых содержит некоторое число элементов (Element), которые могут иметь один из фиксированного числа типов (Type1,...TypeN). То есть по сути Unit представляет из себя древовидную структуру, фиксированной глубины, листьями которой являются Element-ы. Каждая из сущностей (Unit, Package, Group, ElementOfTypeN) имеет свой набор атрибутов.

Для подобных юнитов существует операция "сериализации/десериализации". Эта операция должна предоставлять возможность использования внутри себя разных механизмов. Например, простейший вариант — сериализовать в виде XML документа в файл. Другой вариант — это сериализовать юнит в файловую структуру, где Unit, Package, Group — директории, Element — файл, причем сериализация может проходить как в локальную файловую систему, так и через, например, FTP. Третий варинт — сериализация в БД.

Вопрос — как бы вы предложили организовать такой функционал с точки зрения паттернов-интерфейсов-классов? На верхнем уровне напрашивается паттерн Strategy. А вот дальше? Хочется прежде всего отделить обход дерева от непосредственной "сериализации" конкретной сущности.

Обязанности архитектора ПО

Thu, 25 Feb 2010 19:53:52 GMT

Извините, если баян. Хотелось бы узнать, какие у архитектора ПО вообще обязанности при "правильном" подходе к разработке ПО. Вопрос чисто практический.

Посоветуйте софтина или либа для анализа текста

Thu, 25 Feb 2010 13:02:17 GMT

Сорри, если не очень подходящий форум... но более подходященго не нашел.

Возникла проблема анализа текста и преобразования его в комманду. Например, приходит текст "Какой у меня баланс?" или "Сколько денег у меня на счету?", надо чтобы любое из этих сообщений преобразовывалось в комманду "balance_request", ну или что-то в этом роде. Очень надеюсь, что уже сущесвует какая-то софтина или библиотека, которая умеет это делать. Желательно на java.
Ну или может кто-то уже решал подобную проблему и может что-то хорошее посоветовать?

Фабрика объектов

Thu, 25 Feb 2010 12:14:44 GMT

Возьмем модульную архитектуру , есть несколько базовых типов объектов, каждый базовый тип описан в своем модуле.
У каждого базового типа есть производные типы, в зависимости от состояния программы ( оно одно для всех ) используется тот или иной производный тип.

в коде в зависимости от состояния нужно выбирать нужный объект

CBaseA* object_a;

switch( state )
{
  case 1: object_a = new CDerivedA1(); break;
  case 2: object_a = new CDerivedA2(); break;
}

естественно это использовать во всех местах кода где идет использование объекта типа CBaseA неудобно и лучше сделать 1 раз фабричный метод

static  CBaseA* CreateObjectA()
{

switch( state )
{
  case 1: return new CDerivedA1();
  case 2: return new CDerivedA2();
}

}

Вот возникает вопрос, где лучше этот метод описать — есть 2 варианта , 1й — в самом базовом типе CBaseA, CBaseB и т.д. C,D,E... в виде статического метода, 2й — создать статический тип CObjectFactory и в нем статическими методами описать создание объектов каждого типа A, B, C, D и т.д.

Что же получается в результате в обоих вариантах — зацикленность или избыточность ссылок

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

2й вариант — синглетон CObjectFactory который может создать объект любого типа A, B, C и т.д., он получается зависим от всех модулей, при этом остальные модули вроде как от него отделены и не связаны между собой — на первый взгляд то что нужно. Но вот допустим модуль B решил использовать объект модуля А , соотвественно создать этот объект он теперь должен через фабрику, как только мы подключим фабрику получится что объект модуля B становится зависим от всех остальных модулей которые фабрика может создавать.

Как это решается ?

Схема IT-Инфраструктуры предприятия

Wed, 24 Feb 2010 15:18:38 GMT

Привет.

Для составления документации в одном из проектов мне понадобилась красивая диаграмма/схема
идеальной IT-инфраструктуры крупной компании.
Т.е что бы там были отмечены используемые продукты

— CRM
— ERP
— Утилиты мониторинга — Hp Open View, Tivoli Performance Viewer и т.п.
— Базы данных
— Прикладные пакеты
— Приложения для управления пользователями — Active Directory и др.

Ну и т.п.

Первые полчаса поиска в гугле не дали результата.
Может кто знает где взять такую картинку? Обычно в маркетинговых книжечках IBM'a, Oracle'a печатают подобные диаграммы.
Или придется самому рисовать?

Посоветуйте подход к редактированию б.о. пользователем

Mon, 22 Feb 2010 11:10:28 GMT

Здравствуйте.
Есть бизнес-объект, персистный, при изменении свойств переходит в соответствующие состояния.
Бизнес объект прикреплён к бизнес-транзакции, которая обновляет БД при коммите, там же инициируется валидация зарегистрированных на добавление и обновление объектов перед обращением к БД.

Дело в том, что необходимо сохранять даже невалидное текущее состояние в БД редактируемого объекта.
На уровне БД возможность сохранения текущего состояния реализована, вот пока не придумаю как реализовать сохранение невалидного состояния из BLL.
Может быть подскажете подход?

Обновление: 25 Most Dangerous Programming Errors

Sat, 20 Feb 2010 18:30:32 GMT

Обновился документ 2010 CWE/SANS Top 25 Most Dangerous Programming Errors

Rich какбы.. Обновление связей между объектом и коллекцией

Wed, 17 Feb 2010 19:31:44 GMT

Реализован persistence, в котором объявлен класс, который является базовым для объектов модели.
При изменении свойсв доменного объекта, он меняет своё состояние и регистрирует операцию обновления или удаления или создания в транзакции uow.
В принципе реализован Lazy-load list. При запросе к которому он заполняется объектами домена.

Объект и определённая в нём коллекция других объектов(доступная через lazy-list) связаны через отношение многие ко многим:

ну допустим так...:
Проект.LazyList<Сотрудник>

В БД, так:
Проект 1--*СотрудникиНаПроекте*--1 Сотрудник

Вопрос в том, что при изменении Проект.LazyList<Сотрудник> — списка мне обновить таблицу СотрудникиНаПроекте?

Написать в Менеджере в BLL метод типа ИсключитьСотрудникаИзПроекта(Проект, СотрудникID) ?

[ANN] Руководство MICROSOFT® по проектированию архитектуры

Wed, 17 Feb 2010 10:01:43 GMT

Теперь на русском здесь

Кроссплатформенное приложение

Wed, 17 Feb 2010 06:15:47 GMT

Есть задача написать продукт, который бы синхронизировал данные из гомогенных СУБД
на гетерогенных ОС (windows, linux, unix). Причем, как под 32, так и под 64 бит.
Вопрос: в какую сторону советуете посмотреть? Насколько я понимаю под каждую ОС придется писать свое или же есть умные компиляторы?

Обновление настроек

Tue, 16 Feb 2010 21:30:13 GMT

Есть сетевое приложение, есть объект client, который скрывает все взаимодействие с сервером от других объектов системы.
У некоторых объектов системы есть настройки, которые требуют обновления (допустим ModuleSettings).
Класс Settings инкапсулирует насройки всех модулей.

class Settings
{
private:
ModuleSettings1 ms1;
ModuleSettings2 ms2;
/* ... */
}
// lpArg — указатель на this.settings;
CALLBACK Client::GetSettings( LPVOID lpArg, DWORD dwTimerLowValue, DWORD dwTimerHighValue)
{
Settings *pSettings = lpArg;
*pSettings = DownloadSettings();
}

По таймеру клиент выполняет GetSettings() и загружает свежие настройки с сервера.

Как сделать что бы остальные модули (объекты) могли автоматически обновить свои настройки.

Я думаю в сторону реализации паттерна Observer. Читал про boost::signal, но он не поддерживает multithreading;

Сортировка данных из БД по ресурсам приложения

Mon, 15 Feb 2010 20:58:25 GMT

Всем привет!

Проблема такая:
Есть некоторые данные со статусом лежащие в БД. Статус — типа int (1 — активен, 2 — подписан и т.п.). Доступ к базе через WCF.
Данных много и выбираются они из БД pading'ом с накладыванием фильтров и правил сортировки. В какой-то момент понадобилось сортировать по статусу, причем не по числу, а по текстовому педставлению, но текстовое представление лежит в ресурсах приложения (база ничего не знает про эти тексты).
Собственно вопрос: кто как в таких случаях поступает?

Вопрос по архитектуре проекта

Mon, 15 Feb 2010 15:04:44 GMT

Здравствуйте.

Стоит задача реализовать программу, которая будет получать задачи а результаты выполнения складывать в файл.
Каждая задача это периодически выполняемое действие (вызов какой-то функции).
Всего предполагается 20-50 задач, каждая из которых выполняется один раз в 30-100 секунд.

Соответственно пришел к такому решению:

Для каждого задания создавать свой WaitableTimer (hTaskTimer) и свое событие (hTaskDoneEvent);
Выполнение задачи осуществлять в отложенной процедуре таймера (TimerRoutine) и по её завершении активировать событие hTaskDoneEvent для данной задачи.
В другом потоке (назовем его "поток сбора отчетов") ждать (WaitForMultipleObjects()) активации любого из событий и собирать результаты выполнения.

Насколько удачным является такое решение? и как можно его улучшить?

Пример легкого архитектурного решения WinForms .Net 2.0

Mon, 15 Feb 2010 10:32:18 GMT

Добрый день,

Есть задача написать относительно небольшой проект на .NET 2.0. Как попало писать не охота но использовать что то навороченное типа Software Client Factory не имею возможности, т.к. есть ограничение в версии фреймворка и в дальшейшем на поддержку будет выделен разработчик не особо сильного уровня.

Подскажите пожалуйста легкий пример велосипеда для написания WinForm приложений в котором было:

— Класс App (singleton) от которого все бы плясало.
— реализация паттерна Command
— какой нибудь механизм представления Item-View
— не сильная привязка системы к UI чтобы была возможность запуска в режиме консоли и работы с бизнес объектами.