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

Где хранить Entites?(Те что в Business Layer) Возможно бред!

Fri, 12 Mar 2010 12:24:56 GMT

Пишется приложение основаное на модуляризации. Т.е широко будут использоваться плагины.
В принципе вся логика приложения будет разбита и реализовываться в куче библиотек.
Возник вопрос. Как организовать работу с Entities. Где их объявлять (хранить).
Есть два варианта:

1. Хранить ВСЕ сущности в какой-нибудь Entities.dll и "цеплять" эту dll к каждой новой разрабатываемой библиотеке New.dll. И тогда New.dll сможет спокойно обращаться к сущностям через Entities.dll

Недостатки:

Entities.dll со временем будет очень "тяжелая". Не очень разумно к каждой New.dll цеплять Entities.dll ради какой-то одной необходимой сущности, которую нужно использовать в New.dll

Преимущества:

Простота использования

2. Объявлять и хранить каждую сущность в той библиотеке, в которой это необходимо по смыслу. Там где идет непосредственно работа с данными этой сущности (заполнение, редактирование). Все другие библиотеки ничего не знают ни друг о друге, ни о том где хранится нужная им сущность. Если какой-то библиотеке нужно получить данные из этой сущности — она обращается к главному приложению, или просто отправляет сообщение-запрос о том, что нужно получить данные из какой-то неизвестной сущности (через какой-то интерфейс). Далее приложении ищет в каждой библиотеке нужные данные (по указаному интерфейсу), находит их, и в каком-то виде отправляет назад в New.dll.
Это вообще разумно что здесь описано?
Это похоже на какой-то паттерн проектирования. Может подскажите, есть ли такой?

Преимущества:

Слабая связность
Высокая гибкость
Возможность использования сторонних библиотек, которые реализуют известный интерфейс

Недостатки:

Возможно бред?
Я не знаю как это реализовать

У кого какие мысли по этому поводу?

Интерфейс рисуется отдельно. Логика пишется в библиотеках.

Fri, 12 Mar 2010 09:40:44 GMT

Интересует схема как это собирается вместе.
Если интерфейс рисуется отдельно, логика описана в плагинах...
Из чего в конечном итоге формируется ехе-шник?
Что вообще в этой архитектуре будет из себя представлять ехе-шник?
Что из себя будет представлять архитектура?
Где об этом почитать?

Метод или методы

Fri, 12 Mar 2010 08:11:17 GMT

Хорошего настроения и с весной вас.

Голосование здесь.
Спасибо.

Вопрос возник в результате ленивой беседы с коллегой.
Я всегда предпочитал SetSomething. Но вот, на данный момент, появились легкие сомнения. Мотивация следующая: методы Enable/Disable — вроде как требуют меньшей концентрации внимания при чтении клиентского кода. То есть отсутствует необходимость читать/понимать аргумент (enable он или disable). И похоже это огромный плюс. Минус вижу в разбухании классов и в некоторой асимметрии: логичный getSomething рядом с setSomething и не совсем мм... интуитивный IsSomethingEnabled (хотя это уже более надумано).

Вообще — засомневался, стоит ли предпочесть методы EnableSomething/DisableSomething, но не SetSomething. Ваше мнение?

Инкапсуляция коллекции

Thu, 11 Mar 2010 23:16:58 GMT

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

Допустим есть класс

public class Group
{
  ...
  public readonly CustomCollection Items; // Коллекция кастомная потому что там при добавлении элемента происходит некоторая простенькая валидация
}

Нужно, чтобы при добавлении элемента в группу (т.е. класс представляет собой некоторую группу), он добавлялся в коллекцию и сохранялся в БД.
Сейчас это делается вызовом метода сервиса:

public class GroupService
{
  ...
  public static void AddElementToGroup(Group group, Element element)
  {
    GroupAccessor.AddElementToDb(Group group, Element element);
    group.Items.Add(element);
  }
  ...
}

Проблема например в том, что кто угодно может добавить элемент в коллекцию, или удалить элемент, и не сохранить это в БД.
Т.е. нужно, чтобы только GroupService мог изменять коллекцию.

Какие варианты:

1) Оставить как есть, т.е. если программист изменит коллекцию без сохранения изменений в БД — то он сам виноват. Мне это не нравится.

2) Сделать коллекцию "умной", т.е. чтобы она знала о классе GroupAccessor (класс уровня DAL), и при изменении коллекции, чтобы она сама вызывала методы для сохранения изменений в БД.

3) Сделать класс Group имутабельным, т.е. коллекцию сделать, read only и чтобы для изменении коллекции нужно было создать новый объект Group и передать новую коллекцию в конструктор. Тогда метод GroupService.AddElementToDb() будет возвращать новый объект Group c новой коллекцией (с добавленным элементом). Мне не очень нравится этот вариант. К тому же если у нас есть байндинг на коллекцию, то нужно будет постоянно его полностью обновлять, т.е. например при добавлении элемента в группу переустанавливать DataSource грида (присваивать датасурсу новый объект Group.Items).

4) Можно сделать специальный интерфейс, содержащий методы для изменения коллекции, и explicitly его реализовать. Тогда коллекцию можно будет изменить только после каста к этому интерфейсу. Т.е. программеру уже будет сложнее просто так добавить элемент в коллекцию. А класс GroupService будет делать приведение к этому интерфейсу и добавлять элемент в коллекцию. Вариант не самый красивый, и не гарантирует полной защиты от дурака, но все же повышает инкапсуляцию. К тому же явная реализация интерфейса как раз иногда использоваться для таких задач.

Что посоветуете?

Посоветуйте технологии

Thu, 11 Mar 2010 04:23:02 GMT

Есть система "БД — шлюз — клиент".
Шлюз — серверная программа принимающая информацию от клиентов и других источников и взаимодействующая с БД.
Для работы пользователя предполагается два вида клиентов — десктопный и Web.
Подскажите пожалуйста какие технологии лучше использовать для разработки каждого звена из требования оптимального соотношения стоимости разработки и качества.
Пока мое представление такое:
Шлюз: С++ (возможно Java, сомневаюсь на счет производительности)
Web клиент: PHP (возможно ASP.NET, но напрягает привязка к Windows)
Десктопный клиент: Java

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

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