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

Enum + таблица справочник

Sun, 12 Feb 2012 16:06:18 GMT

Есть таблица справочник [ID,NAME], ~100 записей, постоянно пополняемая.

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

public enum States
{
  sNew = 1,
  sDeleted = 2,
  ...
}

Но в этом случае возникает проблема синхронизации ID таблицы и значений которые у Enum.
Как лучше делать чтоб отслеживать несоответствие или тут уже никаких вспомогательных вещей не придумать ?

SQL в ArgoUML

Thu, 09 Feb 2012 20:28:45 GMT

хочу попробовать сделать генерацию SQL кода по UML диаграмме в ArgoUML,
используя проект dbuml (http://argouml-db.tigris.org/)

Делаю самую простую диаграмму и пробую сгенерить SQL код
вываливается ошибка

Generate source failure. Database factory class {0} cannot be found.

Я что-то не догоняю что ему не хватает ? В документации это не указывается

Спасибо

Генерация клиентов на разных языках для HTTP API

Thu, 09 Feb 2012 13:35:46 GMT

Имеется HTTP API. Примерно такое:

# list
GET /objects/ -> [obj1, obj2, ...]

# create
POST /objects/ -> 201, Location: /objects/someid/

# details
GET /objects/some-id/ -> {'i': 'am some object'}

# update
PATCH {'foo': 'bar'} /objects/some-id/ -> 303, Location: /objects/some-id/

Изобразил достаточно схематично, но, думаю, схему работы понять можно.

Задача: минимальными усилиями создать и поддерживать клиентские библиотеки для множества языков, в первую очередь для Python, Haskell и Erlang, но вскоре потребуются и C#, и Java, и много других

В голову пришли два варианта:

1) Пишем работу с API на C, подключаем к другим языкам в виде библиотеки.
2) Генерируем «низкоуровневые» функции из EDSL на Haskell.

После этого, само собой, пишем более «высокоуровневый» код, чтобы «вписать» библиотеку в язык (чтобы она не выглядела чужеродно).

Кто-то наверняка уже делал подобное, поделитесь опытом. Может, есть какие-то подводные камни, которые я не заметил. Как вообще принято решать такие задачи?

Организация логгирования

Thu, 09 Feb 2012 09:57:19 GMT

Доброго времени суток всем!
Я тут озадачился вопросом оптимизации процесса логгирования в своих программах.
Речь о логгировании работы, например, Win-сервиса.
В логе фиксируются факты запуска и остановки сервиса, получение и переход между этапами выполнения команд, получаемых от клиентов сервиса, ошибки само собой и т.п.
Допустим, средство логгирования выбрано log4net, "родной" System.Diagnostics.EventLog или любой другой (не важно).

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

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

class FirstService
{
  ILogger logger;
...
  void ParentMethod()
  {
    SecondService serv = new SecondService();
    serv.Logger = logger;
    ...
    serv.Method();
    ...
  }
}

class SecondService
{
  public ILogger Logger { get; set; }
...
  void Method()
  {
    SqlConnection cn;
    ...
    cn.Open(); // действие, выполнение которого надо залоггировать
    Logger.Info("Соединение с базой данных прошло успешно"); // можно обратиться к логгеру прямо здесь...
    ...
  }
}

или этот:

class FirstService
{
  ILogger logger;
...
  void ParentMethod()
  {
    SecondService serv = new SecondService();
    serv.ConnectionSuccess += new EventHandler(OnConnectionSuccess);
    ...
    serv.Method();
    ...
  }
  void OnConnectionSuccess(object sender, EventArgs e)
  {
     Logger.Info("Соединение с базой данных прошло успешно");
  }
}

class SecondService
{
  public ILogger Logger { get; set; }
...
  void Method()
  {
    SqlConnection cn;
    ...
    cn.Open(); // действие, выполнение которого надо залоггировать
    ConnectionSuccess(this, EventArgs.Empty); // ... а можно отсюда сгенерировать событие и вызывающий пусть сам решает логгировать или нет...
    ...
  }
...
  public event EventHandler ConnectionSuccess;
}

А может какой-нибудь другой?
Первый вариант, вроде менее многословный, зато во втором процесс логгирования более централизован...
Как лучше?

ORM и пакетные операции

Mon, 06 Feb 2012 13:07:32 GMT

Здравствуйте.
Суть такова: допустим пишется проект в стиле DDD. Есть класс MyObject, с помощью ОРМ он отображается на таблицу, и у этого класса есть, скажем, какое-то вычисляемое свойство, которое обновляется при вызове метода.
А этот метод таков, что он обращается к БД.

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

Можно это оптимизировать и внешним кодом извлечь целую табличку значений и из нее уже обновить значения свойств у всего списка объектов.

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

Архитектура приложения с GUI и очередь нотификаций

Sat, 04 Feb 2012 15:51:32 GMT

Всем привет.
Не знал куда запостить вопрос, сюда или в С++.

Пишу прикладную утилиту на С++\МФЦ под Вин. Утилита выполняет определенные действия(долгие) над выбранным участком жесткого диска. Возник вопрос по архитектуре такого ПО.

Итак, у меня есть GUI thread, в котором крутится обычный виндовый цикл выборки сообщений и работает само GUI. Чтобы GUI не тормозило, я обычно делаю еще один поток — Core thread, который собственно управляет логикой самой задачи (и зачастую запускает уже конкретные задачи в других потоках). Core thread обменивается с GUI thread нотификациями (сообщениями, но не виндовыми а своими собственными).
Выглядит это примерно так
GUI --> посылает команду--> *потокобезопасная очередь сообщений* --> ядро вычитывает команду --> Core thread
В другую сторону есть другая сходная очередь.

Базовый вопрос:
Есть сообщения(команды) с данными. К разным сообщениям прикреплены совершенно разные данные. Типа:

struct Msg
{
 int id;
 void* pData;
}

Но мне не нравится void* . Как (не используя сторонние библиотеки) написать сообщения, которые были более безопасны по типу (не надо было бы привозить void* в зависимости от id а использовать какую-то другую структуру сообщений)? Или и так нормально? Дата может быть большим объемом данных, который надо аллоцировать при отсылке и уничтожать после чтения — сейчас это делается "вручную".

Второй вопрос — все ли нормально с общей архитектурой или есть какие-то паттерны, которые лучше подходят к таким приложениям?

DAL: распределенные транзакции или групповые операции?

Fri, 03 Feb 2012 13:23:35 GMT

Привет.

Проектирую слой служб доступа к данным (вебсервис).

Вопрос в следующем: операции над сущностями делать изначально групповыми (2) или штучными используя распределенные транзакции (1)?

1.

BeginDistributeTransaction();
  foreach (contracts)
    DeleteContract(Contract contract)
CommitDistributeTransaction();

DeleteContracts(Contract[] contracts)

Выбор архитектуры для CRUD-подобного приложения на WPF

Thu, 02 Feb 2012 10:31:40 GMT

Сейчас написано клиент-серверное (двухзвенное) приложение на WPF и Entity Framework для редактирования автобусных расписаний. Все устраивает, кроме проблемы одновременного доступа, например, если кто-то редактирует расписание, а кто-то другой его в это время удаляет. Поскольку пользователей немного, и, как правило, каждый отвечает за свой набор расписаний, сделал простую блокировку — при открытии расписания следующий пользователь может открыть только для просмотра. Работает не идеально, но просто в реализации и особых проблем не доставляет (в худшем случае — падает клиентское приложение).

В ближайшем будущем нужно написать другое приложение (либо встраивать новый функционал в текущее), там пользователей уже будет больше. Хочется решить проблему одновременного доступа более надежным способом. Более того, хочется, чтобы изменения одного пользователя в реальном времени отображались в интерфейсах других пользователей (как, например, в Google Docs, только без редактирования текста в реальном времени). Кроме того, нужно автоматически обрабатывать новые данные, поступающие извне. Заталкивать эту обработку в хранимые процедуры как-то совсем не хочется.

Сразу подумал о трехзвенной архитектуре: клиентские приложения на WPF почти без логики, которые через WCF подключаются к среднему звену на сервере (через двухстороннюю связь, чтобы транслировать клиентам обновления данных), в котором сосредоточена вся логика, а среднее звено через EF работает с базой данных. Обмен данными между клиентом и сервером приложений — через Self-Tracking Entities (клиенты пишутся только на .net).

Теперь вопросы:

1) Жизнеспособна ли такая архитектура, или я упускаю что-то важное (посмотрел отдельно примеры по WCF, STE, вроде то, что нужно, но описания решения в целом нигде не видел).
2) Не променяю ли я сложность синхронизации клиентов в двухзвенной архитектуре на сложность реализации трехзвенной архитектуры, и если променяю, стоит ли оно того (классические преимущества трехзвенки, типа масштабируемости и легкой возможности замены клиента для меня малоприменимы).

3) Как вообще ведется разработка серверной части?

Вот я сейчас как пишу клиентское приложение:

— реализую кусочек функционала,
— запускаю, проверяю,
— если все ок, делаю commit и push в меркуриале
— делаю паблиш через ClickOnce
— пользователи сами загружают новую версию при старте программы
— время от времени смотрю логи пользователей/тестировщиков, все ли ок

А если я пишу сервер приложений (среднее звено, сервис WCF, как это вообще правильно называть), допустим, я хочу, чтобы он в итоге работал как служба Windows на сервере и сам перезагружался после падения (а падения будут, особенно много поначалу), то вот что меня отпугивает: я же не смогу так просто запустить из студии серверную часть, проверить, что-то поменять, снова проверить. Мне придется каждый раз куда-то устанваливать эту службу и перезапускать. Не потрачу ли я на это слишком много времени (по сравнению со старым добрым клиент-серверным подходом, где сервер БД живет своей жизнью, а отладка клиента тривиальна)? Или делать поначалу как консольное приложение? Его не надо никуда устанваливать, запустил и все.

В общем, стоит ли менять простую в понимании клиент-серверную архитектуру на заманчивую и более современную трехзвенную?

(Если честно, хочется поменять, хотя бы ради опыта, вопрос в том, чего мне это будет стоить, у начальства терпение тоже не безграничное, у них денег на крутых специалистов нет, но результат-то нужен, в связи с этим они готовы пожертвовать 100% качеством ПО, то есть, "можно делать как попало, потом разберемся, лишь бы уже работало". Но по срокам сильно не давят, определенное пространство для маневра есть. Так, например, Entity Framework уже сэкономил мне прорву времени, хотя я и изучал его прямо по ходу дела. Сэкономит ли мое время WCF?)

Пока что думаю написать простой прототип, но и сейчас любая информация лишней не будет.

Если кто-то поделится опытом или ссылками на классные источники (вдруг есть в закладках, да и просто "видел там-то у того-то"), буду весьма благодарен.

Гарантированная обработка сообщений

Wed, 01 Feb 2012 23:10:08 GMT

Уже не в первый раз в своей жизни столкнулся с следующей задачей:

Есть очередь задач, которую необходимо обработать. Обработка идет несколькими worker, параллельно.
В очередь задачи также укладываются несколькими producers.
Очередность выполнения не важна.
Вроде бы — обычный Message Queue, все стандартно.

Но хочется иметь еще и "гарантированную обработку сообщений". Т.е. если воркер взял себе задачу — то он или ее выполнит — или вернет в очередь "на повторную попытку".

В свое время (2008 год) мы с Яшей Сироткиным ее решали через хранение очереди в БД и некоторые хитрые фишки в SQL (типа 'skip locked'). Как быстрое наколеночное решение оно вполне устроило, даже доклад сочинился (http://www.jug.ru/servlets/images/meeting_2008_09_20/query.ppt, ну и обсуждение на http://yakov-sirotkin.livejournal.com/103083.html)

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

Какие есть решения, какие идеи?

Статистика использования сервисов

Wed, 01 Feb 2012 16:51:23 GMT

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

Есть примерно следующая задача:

Есть несколько служб реализующих некоторый функционал.
Нужно собирать статистику по использованию этих служб — результат аутентификации пользователя, вызовы методов служб и параметры с которыми вызывался метод конкретным пользователем. Цель — возможность иметь информацию по использованию данных на любой момент времени, включая такую информацию как: сколько пользователей обращалось за последнюю минуту/час/сутки, какие параметры предпочитал пользователь (например, используемый договор) и т.д.

Вариантов реализации вижу два (три):
1. Парсинг логов. Да, логи ведутся, достаточно подробные.
2. "Велосипед" на тему записи только нужной части информации в некоторое "хранилище" в подходящем виде (структурированном?).
3. Служба (MSMQ) регистрации такой статистики. Дергается в нужном месте.
4. ?

Еще вопрос касательно хранения такой информации в структурированном виде для последующей обработки. Тут пока даже не представляю как. Контракты служб могут в будущем меняться.

Возникала ли у вас подобная задача, как вы ее решали? Что я не учел? Или задача тупо надумана?

Как правильнее сделать адаптер

Sun, 29 Jan 2012 11:54:07 GMT

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

Например один провайдер возвращает

<?xml version="1.0">
<root>
  <a></a>
  <b></b>
  <c></c>
</root>

Другой может возвращать следующим образом

<root>
  <lista>
    <a></a>
  </lista>
  <b/>
  <d/>
</root>

У второго свойство <a/> завернуто в список, данный провайдер поддерживает множественный запрос ( чтобы не вызывать по одному запросу ) и в ответ может вывести сразу множество a.
Как лучше организовать структуру данных в БД и объектов для хранения данных ?

Допустим также появится 3й провайдер у которого будет свойство <e/> чтобы это приводило к минимуму изменений кода.

Пока думаю сделать следующий объект

public class Result
{
   string a;
   string b;
   string c;
   string d;
}

Адаптер для каждого провайдера будет содержать свой класс совпадающий по структуре с XML провайдера, который будет инициализироваться через XmlSerialization, и потом с помощью в основном Linq преобразовываться в IEnumerable<Result> , т.е. провайдеры которые поддерживают только 1 запрос за раз — будут возвращать IEnumerable с одним элементом.

И аналогично хранить в базе таблица с колонками a,b,c,d. Когда появится свойство e, то добавить колонку и поле в Result.

Насколько такая реализация будет правильной ? Возможно есть более интересные варианты реализации.
(.net 4.0 )

Three-tier acrhitecture и firewall

Thu, 26 Jan 2012 19:30:44 GMT

Извиняюсь за глупый вопрос.
Допустим есть фаерволл в виде виндового сервиса. Есть консоль к нему, где можно задать некие настройки, посмотреть какую-то информацию статусы и т.д.
Можно ли говорить об этом приложении в терминах трехуровневой архитектуры (three-tier architecture) и почему? А если нет, то воплощает ли такой фаерволл какой-то другой паттерн аналогичный 3-tier architecture?
И консоль в данном случае вроде на presentation tier не тянет, ведь результат работы приложения отображается не в ней, а в действиях самого фаерволла.

Cqrs

Thu, 26 Jan 2012 19:22:17 GMT

Подскажите как правильно, при обработке команды обратиться к read-модели. Например пришла команда на изменение баланса, и если это уже более чем десятое снятие со счета должны начислить определенную комиссию.

[design patterns] Factory Method and Template Method

Thu, 26 Jan 2012 14:19:22 GMT

можете на пальцах объяснить — чем subj отличаются друг от друга?

подскажите паттерны

Tue, 24 Jan 2012 18:24:43 GMT

Есть некие связанные между собой объекты, к примеру, удаленные офисы, компьютеры, пользователи
предлагается показывать их с список в окне с деревом, с возможным фильтром по типу объектов (или с группировкой по ним — это уже не суть важно), в окне конечно есть кнопочки панели инструментов (естественно у каждого типа должен быть свой набор)
Действия пользователя такие — зашел получил дерево вида офис -> компьютеры офиса -> пользователи компьютера
выбрал другой фильтр получил пользователь -> офисы где пользователь работает -> компьютеры офиса на которых пользователь работает

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

Дайте правильное направление, что посмотреть, почитать.
Спасибо.

Как лучше делать Observer?

Mon, 23 Jan 2012 04:46:28 GMT

Сейчас прижилась структура приложений на WPF с использованием MVVM и Composite. При этом связь между уровнями MVVM оказывается удобнее один ко многим, т. е. на уровне model по одному экземпляру сущности, на уровне view их столько, в скольких видах нужно представить пользователю, а view model по соображениям удобства. Так вот если связь view — view model один ко многим делается стандартными средствами, то относительно связи model — view model всё очень неоднозначно, а копировать стандартные средства — не всегда самый удобный вариант.

На wikipedia пример Observer совсем незатейливый, в качестве наброски его можно использовать, но обновлять все свойства при изменении одного — не лучшее решение. Есть варианты использования enum или событий на логические группы свойств — это под вопросом. Особая ситуация, если следующий уровень по Composite представлен коллекцией. Здесь есть вариант и пользоваться интерфейсом INotifyCollectionChanged, есть вариант возвращать всегда ReadOnlyCollection, а обновление делать методами Add, Remove и т. п., но удобство тоже под вопросом.

Ещё один существенный момент — дублировать как можно меньше строк, т. е. вынести как можно больший кусок в собственный стандартный набор инструментов, а в конкретных приложениях писать как можно меньше и обеспечить минимум возможностей сделать ошибку в конкретном приложении, т. е. как б отладить один раз и дальше использовать везде.

Расскажите, пожалуйста, кто как делает Observer, какие есть лучшие решения по этому вопросу и как лучше сделать reusable-фрагменты.

С чего начинать?

Sat, 21 Jan 2012 13:47:01 GMT

Получили в наследство проект без документации.
ASP.NET (web forms) + MSSQL 2005.
Работа с базой идет через ADO.NET.
В базе порядка 1000 процедур и 600 таблиц.
Процедуры — непростые — везде работа идет через динамические запросы.

Вопроса 2.
1. Если наадо что-то добавить, как не накасячить, чтобы где-то что-то внезапно не перестало работать?
2. Если времени на глобальный рефакторинг нет, но в задачах сильно на сроки не давят, как потихоньку делать рефакторинг?

2.1. Есть ли смысл не делать рефакторинг, а просто потихоньку начинать делать на MVC новый проект? правда не уверен, что это будет по силам, т.к. проект несколько человеколет

Что должен уметь класс изображения?

Fri, 20 Jan 2012 15:22:23 GMT

Собственно вопрос в названии темы. Как вы думаете, должен ли этот класс иметь методы для изменения себя или он должен быть только для чтения, а для его изменения сделать отдельные функции?
И какую лучше архитектуру использовать для него:
Например хотим создать изображение в формате RGB:
Image<RGB> img1(width,height); //ок
хотим создать изображение в формате YUV(YCbCr):
Image<YUV> img2(img1); //ок
хотим использовать изображение в формате YV12(подвид YUV, где элементы U и V одни на каждый квадрат 4x4 пикселя)
Image<YV12> img3(width,height); //а может лучше использовать img2, но если нужен будет буфер с изображением в формате YV12 сделать так:
std::vector<uint8_t> buf_yv12;
get_buf_in<YV12>(buf_yv12,img2);

Хочу услышать ваше мнение...

Помогите с реализацией класса Pair

Thu, 19 Jan 2012 10:55:36 GMT

Извините, за глупый вопрос. Но может можно реализовать такое?

 public class Pair<TFirst, TSecond> 
    { 
        public Pair(TFirst first, TSecond second) 
        { 
            First = first; 
            Second = second; 
        }

        public Pair<TFirst>(TFirst first, TFirst second) : Pair<TFirst, TFirst>(first, second)
        {
        }

        public readonly TFirst First;
        public readonly TSecond Second;
    };

Как правильно связать объекты граф интерфейса и DomainModel

Thu, 19 Jan 2012 10:24:51 GMT

Есть у меня DomainModel и там сложное переплетение классов. И несколько должны создаваться за 1 раз, типа транзакции. И вот нужно упростить пользователю процесс ввода. Я делаю так.

Есть у меня как бы основной для группы классов DomainModel класс и в нём конструктор

 public MainDomainModel(UserComplexObject complexObject)

Т.е. я пользователю вывожу форму и там заполняю экземпляр класса UserComplexObject а потом передаю его в конструктор. А сам конструктор создаёт вспомогательные объекты. Правильно ли такое решенеи? Или в контреллер перенести логику создания DomainModel объектов на основе вспомогательного класса? Или вообще городить вспомог классы преобразования. Но вроже бы они и не нужны больше нигде, да и в иерархию их не получится организовать (общего будет мало)

Гуру, подскажите, кто как делает?