Давайте посмотрим на гениальное произведение технической мысли: фрезерный обрабатывающий центр V700 фирмы СтанкоМашСтрой.
Цена этого чуда составляет всего-навсего 35 миллионов рублей.Несложно предположить, что еще ему нужно помещение и электричество эдак киловатт 30, далее различные расходники типа режущих головок и сменных насадок, периодическое тех.обслуживание, чистка, смазка и так далее.
К этому станку нужно поставить рукастого и головастого рабочего, который будет в правильном порядке нажимать кнопки и инженера, который сможет подготавливать 3Д модели деталей и продумывать программу выполнения обработки.
Учтем естественный износ деталей и амортизацию и предположим, что его срок жизни 10 лет. Это даст «временной распад» порядка 300 тыр/мес.
Итого можно прикинуть, что ежемесячная стоимость владения этим чудом составит порядка 400-500 тыр/мес. Может и больше.
0:00 Куда я пропал со smart-lab.ru
01:09 Почему мне больше не интересна политика
01:58 Почему мне вообще были интересны политические темы
03:00 Как изменился Саратов за последний год
04:20 Почему меня потянуло на «высокое»
06:20 Для чего нужно учить стихи. Какая связь с трейдингом
07:50 Пушкин и золотой запас
09:00 О чем буду говорить дальше
Приветствую. В предыдущем посте описывался интерфейс для генерации тиковых данных – ITickGenerator. Его реализации могут быть разными: данные могут генерироваться на лету, или браться из БД. В случае с БД, возникает необходимость в организации ещё одного слоя приложения – слоя доступа к данным. TickGenerator, всё также будет оповещать подписчиков (стратегии, которые выставляют заявки), но по тем данным, которые он получит из БД.
Сейчас не важно, какая будет база данных, и где она будут храниться – на сервере, в файлах или в оперативной памяти. Не важно, также, какие специфические библиотеки и драйвера буду для этого использоваться. Сейчас, я просто приведу пример того, как можно разделить бизнес-логику приложения и слой доступа к данным.
Я создал отдельный модуль, и там и развернул всю архитектуру, связанную с БД, основные компоненты которой: сущности, репозитории и дата-сервис.
Хотя понятие сущности (Entity), само по себе, достаточно общее, здесь, буду применять его в узком смысле – это классы, представляющие таблицы БД, возможно, с какой-то дополнительной логикой. В простейшем случае, одна сущность – одна таблица. Между сущностями может быть связь (например, один ко многим), которая отражается и в связи между таблицами. Сущность описывается полями класса, которые отражают колонки таблиц.