Здравствуйте, vgrigor1, Вы писали:
V>Почему не хочешь использовать уже готовые квази- програмныерешения V>с возможностью настройки, например 1С чего-нибудь.
V>Там много наворочено чего тебе надо, V>вместе с заготовками бизнес логики V>и трех-уровненвой современной и двух как у тебя архитектурой.
V>Почти все сделано за тебя, плюс язык настройки, V>почему бы нет?
Прошу пардон, но что есть трёх уровневая архитектура...?
Возможно 1С это выход, но меня в данный момень интересует не на чём проектировать , а как проектировать...?
M>Прошу пардон, но что есть трёх уровневая архитектура...? M>Возможно 1С это выход, но меня в данный момень интересует не на чём проектировать , а как проектировать...?
Сначала надо поставить свои програмные цели.
(Поэтому надо спросить: а какие бывают хорошие архитектуры, если не знаете, для таких систем требований?)
Перечисляете варианты... Выбираете лучший для вас.
Потом найти тот инструмент которым он лучше удовлетворяет с учетом перспективы.
То есть на чем эти хорошие варианты делаются.
Здравствуйте, vgrigor1, Вы писали:
V>Почему не хочешь использовать уже готовые квази- програмныерешения V>с возможностью настройки, например 1С чего-нибудь.
V>Там много наворочено чего тебе надо, V>вместе с заготовками бизнес логики V>и трех-уровненвой современной и двух как у тебя архитектурой.
V>Почти все сделано за тебя, плюс язык настройки, V>почему бы нет?
Тот не может считаться настоящим бизнес-программистом, кто не написал ни одной складской программы...
... << RSDN@Home 1.0 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
............... V>Потом найти тот инструмент которым он лучше удовлетворяет с учетом перспективы. V>То есть на чем эти хорошие варианты делаются.
Советую изучить(желательно изнутри) 4-5 вариантов готовых складских программ. Разобравшись как они работают, ты сможешь ответить на вопрос, каким образом нужно проектировать твою программу. С другой стороны, я думаю, что после этого у тебя пропадет желание писать что-то свое и ты воспользуешься готовым, доработав это для своего конкретного случаю (благо что большинство современных учетных систем позволяют это сделать).
Здравствуйте, DemAS, Вы писали:
DAS> Советую изучить(желательно изнутри) 4-5 вариантов готовых складских программ. Разобравшись как они работают, ты сможешь ответить на вопрос, каким образом нужно проектировать твою программу. С другой стороны, я думаю, что после этого у тебя пропадет желание писать что-то свое и ты воспользуешься готовым, доработав это для своего конкретного случаю (благо что большинство современных учетных систем позволяют это сделать).
Что то похожее на "Platform 2003" показывали, но это ведь не реально работающая система. Мне бы хоть одну реально работающую ее имплементацию кто бы показал. Тем более доступ к данным основан на вебнутых сервисах, что не удовлетворяет меня.
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, kreek, Вы писали:
K>>Только вот n-tire я еще не одной не видел.
DAS> Navision Axapta — гораздо большее чем простая складская программа, но зато трехзвенка
Она позиционируется как ERPII, только вот нет возможности ее изнутри пощупать, да хотя бы Attain.
Здравствуйте, kreek, Вы писали:
K>Она позиционируется как ERPII, только вот нет возможности ее изнутри пощупать,
Смотря что ты имеешь в виду. В Аксапте есть хорошая среда разработки, ты имеешь достум ко всем данным(таблицам), к их структуре и к алгоритмам, которые работают с этими данными. По моему, этого достаточно, чтобы представить себе всю нереальность проектирования подобной системы одним человеком
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, kreek, Вы писали:
K>>Она позиционируется как ERPII, только вот нет возможности ее изнутри пощупать,
DAS> Смотря что ты имеешь в виду. В Аксапте есть хорошая среда разработки, ты имеешь достум ко всем данным(таблицам), к их структуре и к алгоритмам, которые работают с этими данными. По моему, этого достаточно, чтобы представить себе всю нереальность проектирования подобной системы одним человеком
Один, конечно, не потянет. Аксапту я вообще считаю, как одну из технологически продвинутых ЕРП систем, тем более теперь она у Микрософта. Также обещают в скорем времени выпустить Business Framework, может тогда полегче станет делать системы такого уровня.
Здравствуйте, Mazi, Вы писали:
M>Нужно написать складскую программу.... M>С системной архитектурой определился : M>Клиент — пишу на С#.Net M>Сервер — MS SQL 2000
M>А вот с бизнес — логикой что то не очень...
Здравствуйте, Mazi, Вы писали:
M>Нужно написать складскую программу.... M>С системной архитектурой определился : M>Клиент — сервер M>Клиент — пишу на С#.Net M>Сервер — MS SQL 2000
M>А вот с бизнес — логикой что то не очень...
M>Чего можно подчитать? Не подкинете какие нибудь ссылочки M>Желательно на русском...
Самый лучьший пример — Bank Microsoft. Вся суть подобных
задач синхронизация (без потерь производительности) запросов.
Клиент-сервер не годится. Хотя бы трехзвенная архитектура.
вы помнится писали весьма симпатичный проект,
с ХМЛ универсальной обьектной модльею системы.
Раз ХМЛ видимо эта штука у вас проектно-независимая,
то есть библиотека, (что в смысле ДОМ для всех, таких DB проектов,- гибкий),
обычно трудно сделать на чистом С++,
у вас там гибкость настройки, скрипты, бизнес логика,
все очень универсально, то есть снова отдельная от специфики
проекта архитектура,
То есть вся может быть отделена от специфики.
то есть всем таким, и вообще, может быть интересно,
вы не опишите что у вас получилось?
Винтовку добудешь в бою!
Re[9]: Проектирование складской программы
От:
Аноним
Дата:
10.01.03 23:47
Оценка:
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, kreek, Вы писали:
K>>Она позиционируется как ERPII, только вот нет возможности ее изнутри пощупать,
DAS> Смотря что ты имеешь в виду. В Аксапте есть хорошая среда разработки, ты имеешь достум ко всем данным(таблицам), к их структуре и к алгоритмам, которые работают с этими данными. По моему, этого достаточно, чтобы представить себе всю нереальность проектирования подобной системы одним человеком
Ну почему? Вообще то, вполне реально. По крайней мере, двум трем. Я бы пожалуй, сейчас, один за годик справился, но правда, лагодаря тому, что у меня пять лет опыта в разработке подобных вещей. Не ERP-конечно,но вполне приличный складской учет, с мат бухгалтерией. Впрочем вру. Мой опыт показывает, что бухгатерию, как и ремонт, можно только начать, но никак не закончить. Если пишешт для преприятия на котором сам работаешь, то никаких проблем, если на заказ... Лучше не буду выражаться.
Кстати, а насколько реально найти гденибудь или скачать бесплатно пиратскую Аксапту... Было бы любопытно взглянуть. Особенно интересует CRM одуль. И вообще, не посоветует ли кто нибудь какие-нибудь демо или пиратские CRM для изучения?
Здравствуйте, <Аноним>, Вы писали:
А>Кстати, а насколько реально найти гденибудь или скачать бесплатно пиратскую Аксапту... Было бы любопытно взглянуть. Особенно интересует CRM одуль. И вообще, не посоветует ли кто нибудь какие-нибудь демо или пиратские CRM для изучения?
Скачать демку аксапты можно, но там не дадут ковыряться во внутренностях, а вот R3 можно посмотреть в онлайне, но тоже как пользователь. Проще всего зазнакомиться с кем-нибудь, кто работает с этими продуктами и ходить в гости
А про хакерские версии вообще ничего не слышал.
Здравствуйте, vgrigor1, Вы писали:
V>Здравствуйте, Akzhan,
V>вы помнится писали весьма симпатичный проект, V>с ХМЛ универсальной обьектной модльею системы. V>Раз ХМЛ видимо эта штука у вас проектно-независимая, V>то есть библиотека, (что в смысле ДОМ для всех, таких DB проектов,- гибкий), V>обычно трудно сделать на чистом С++, V>у вас там гибкость настройки, скрипты, бизнес логика, V>все очень универсально, то есть снова отдельная от специфики V>проекта архитектура,
V>То есть вся может быть отделена от специфики.
Упс. Вы столько превосходных эпитетов подобрали, что даже не знаю, насколько они подходят.
Подсистемка там маленькая, никаких скриптов нет, остальное присутствует. Да, архитектура сделана наоборот — вокруг единого основного XML-документа состояния и справочников сделано ядро с бизнес-логикой, к нему же прицеплен сериализатор состояния.
Клиент видит слой фасадных классов. Сериализатор имеет дело с БД.
На этом всё. Простая архитектура — благодая возможностям .NET.
Фасадные классы выполнены на чистом C++/ATL/XML/XPath. Они обращаются к классам бизнес-логики — которые в виде C#-сервиса, который подгружает C#-библиотеку сериализатора.
Здравствуйте, Akzhan, Вы писали:
V>>То есть вся может быть отделена от специфики.
A>Упс. Вы столько превосходных эпитетов подобрали, что даже не знаю, насколько они подходят. A>Подсистемка там маленькая, никаких скриптов нет, остальное присутствует. Да, архитектура сделана наоборот — вокруг единого основного XML-документа состояния и справочников сделано ядро с бизнес-логикой, к нему же прицеплен сериализатор состояния. A>Клиент видит слой фасадных классов. Сериализатор имеет дело с БД. A>На этом всё. Простая архитектура — благодая возможностям .NET. A>Фасадные классы выполнены на чистом C++/ATL/XML/XPath. Они обращаются к классам бизнес-логики — которые в виде C#-сервиса, который подгружает C#-библиотеку сериализатора.
Что интересного:
Для другого приложения — вы легко поменяете ХМЛ документ,
или там многое жестко завязано, как у вас получилось?
Что здесь только из .Net, на мой взгляд только C# сервисы,
чем они вам понравились больше чем СОМ ?
Остальное ведь отдельно есть?
Надо так понимать у вас между ХМЛ и фасадом, находятся С# сервисы,
зачем эти сервисы ?
Фасада из C++/ATL/XML/XPath не хватало ? Или они уже как обычно представлены ыасадом из сервисов С# ?
В чем смысл? Во внутренней распределенности компонент системы по клиентским машинам?
Спсибо за пояснение,
я протсо нечто подобное делаю в обощенном виде, (генератор — простых -ALL dаtа to GUI+ lite tune,3Levels+GUI -> infrastructure for VC++)
хочется знать какие места слабые, какие конкретно сложно сделать общими -обобщенными?
Здравствуйте, vgrigor1, Вы писали:
V>Здравствуйте, Akzhan, Вы писали:
V>Что интересного: V>Для другого приложения — вы легко поменяете ХМЛ документ, V>или там многое жестко завязано, как у вас получилось?
Основные сервисы ядра вполне reusable, а поверх несколько мелких специализироавнных надстроек — бизнес-функциональность. То есть — ядро может быть переориентировано на другие схемы данных, но бизнес-функциональность, естественно, надо описывать.
V>Что здесь только из .Net, на мой взгляд только C# сервисы, V>чем они вам понравились больше чем СОМ ?
Они у меня вполне COM+/NET/C#. На самом деле писать COM+-компоненты на C# несколько проще, чем на C++/ATL. Плюс к тому в Вашем распоряжении богатейшая функциональность .NET Framework.
DataSet = XML Document — важнейшая фича.
V>Остальное ведь отдельно есть?
Нет.
V>Надо так понимать у вас между ХМЛ и фасадом, находятся С# сервисы, V>зачем эти сервисы ? V>Фасада из C++/ATL/XML/XPath не хватало ? Или они уже как обычно представлены ыасадом из сервисов С# ?
DataSet = XML — только в .NET/ADO.NET. да и писать на C# удобнее.
V>я протсо нечто подобное делаю в обощенном виде, (генератор — простых -ALL dаtа to GUI+ lite tune,3Levels+GUI -> infrastructure for VC++) V>хочется знать какие места слабые, какие конкретно сложно сделать общими -обобщенными? V>Не можете сказать ваше мнение ?
Сложно сказать, так как мне сложно по кратким и несколько сумбурным Вашим фразам составить впечатление.