DrKonito3.5) Расскажите какой вы видите свою систему через 5 лет.
Наверное это вообще самый важный вопрос, когда рассуждаешь о зрелости технологии. Остальные вопросы, честно говоря, риторические - ответьте хотя бы на этот :)
Да ладно, я на все вопросы отвечу, мне не жалко, хотя приходится в выходные этим заниматься – на работе сейчас времени маловато стало…
Если с точки зрения бизнеса все пойдет нормально, то через 5 лет это будет внедряемая своими силами + возможно силами партнеров система + набор типовых решений для построения определенного типа корпоративных приложений. Какого типа – на 5 лет загадывать не буду. Сейчас планируется документооборот, CMS, CRM. Возможно, через 5 лет она будет более специализированной, возможно - наоборот.
DrKonitoОк, мне не жалко переформулирую:
1)Интеграция
С интеграцией у СП плохо не в том случае, когда СП скрывает от клиента подлинный источник данных - здесь у СП все хорошо. Плохо у них, когда стороннему приложению надо взаимодействовать с вашим СП. Расскажите, как в вашей системе решаются вопросы
1.1) построения отчетов
Пока что вручную на ASP.NET. Вообще планируем какое-нибудь готовое средство построения отчетов прикрутить, но какое - пока не определились.
DrKonito1.2) распределенных транзакций
Эта проблема решится с планируемым переходом на .NET 2.0, где проще реализуются возможности a-la COM+.
DrKonito1.3) пакетных заданий
Это вы как раз-таки про шедулер? Честно говоря здесь вообще проблемы не вижу.
DrKonitoЯ не говорю, что ни один из этих вопросов не решаем. Каждый из них решаем в том или ином виде. Вопрос в том, что ради этого вам придется писать кучу нетривиального кода, ради того, что в СУБД уже есть и этим надо просто пользоваться.
На моей прошлой работе ребята полгода собственный шедулер отлаживали (непростая тема оказывается), стандартные не подходили :) Да еще они хотели писать ОлеДб провайдер к своему СП :)
А вы зря смеетесь, и у нас в планах стоит задача написания провайдера данных. OLEDB, ODBC, ADO.NET – это непринципиально. В этом случае автоматически отпадает бОльшая часть проблем, связанных с интеграцией данных.
DrKonitoЯ понимаю, что это очень полезно и интересно с точки зрения чистого програмизма, но когда мне нужен результат с точки зрения заказчика, сами понимаете.
Просто у нас разные задачи и соответственно разные результаты. Вы оцениваете общий подход применительно к своим частным задачам и делаете на основании этого общие выводы, хотя эти выводы применимы только к вашим задачам.
DrKonito2)Эксплуатация
2.1) Деплоймент изменений - каждое изменение в СП - это как минимум рестарт СП, возможно обновление всех клиентов. Зависит от фантазии разработчика.
При двузвенке - это просто прогрузка измененной процедуры. А если изменений несколько в день. Не пробовали? У вас наверное ежедневные билды и релиз раз в месяц? :)
Вы думаете, достаточно прогрузки измененной процедуры? А клиента в этом случае менять не надо? Ну если изменения косметические – то наверное не надо. А если меняется структура данных?
DrKonito2.2) Аудит системы, мониторинг производительности. В СУБД уже все есть ;)
Собственно, тут используются возможности ОС - Event log, Performance counters и т.п. Не вижу никаких проблем в реализации подобных возможностей.
DrKonito2.3) Поиск нетривиальных ошибок в системе, да и тривиальных тоже. Врядли вы в своем СП реализуете, что-нибудь круче обычного SQL-Profiler. Хорошо если у вас есть хотябы БольшойПротокол работы СП.
Ошибки ловятся довольно тривиальным образом, для этого не нужно профайлера. Если проблемы на уровне СУБД – дедлоки, падение производительности и т.п. – они ловятся тем же SQL-профайлером. Если на уровне приложения – для этого просто правильно пишется обработка ошибок с выводом в файл или event log. До сего времени проблем с отловом ошибок не было, хотя ситуации бывали всякие…
DrKonito2.4) Время безостановочной работы системы- как вы думаете, что проработает дольше глючный M$ SQL сервер или даже сто раз вылизанный самодельный СП?
См. пункт 3.1.
DrKonito2.5) Кто может поддерживать ваш СП? Только специально сертифицированные по вашему СП специалисты и разработчики. Первые и вторые это одни и те же люди? ;)
В настоящее время да.
DrKonito3) Зрелость
3.1) Хотели бы в 1980 году внедрять Оракыл у себя на предприятии? Когда еще не было РАДа, ОДБЦ и Оракыл падал и портил данные заказчиков:) Другими словами у меня глубокое ощущение, что идеи СП находятся сейчас примерно на той же стадии развития.
Все-таки в конечном итоге внедряется не Оракыл, а приложение, написанное на нем, которое точно также может падать и портить данные заказчиков. Вопрос только в квалификации разработчиков.
DrKonito3.4) Откуда берётся администратор для вашей системы?
Просто покупается на рынке и начинает делать свою работу? Покупается на рынке и учится с нуля? Какой вариант ваш?
Наш вариант – покупается на рынке и обучается. Администратора за 400 баксов покупать смысла никакого нет, поэтому процесс не будет столь драматичным, как Вы писали на тему обучения кодера :).
Прорезюмирую – я согласен с Вашим выводом о том, что СП – это на настоящий момент незрелая технология. Я отдаю себе отчет в том, что наш СП будет занимать довольно узкую нишу на рынке и не будет настолько универсальным средством, каким является промышленная СУБД. Но это не означает, что надо забить на него и ждать, пока кто-нибудь из больших компаний снизойдет до того, чтобы создать и достаточно продвинуть свой СП в массы.
авторДык!!!!!!!!!!!!! Ёпрст!!!! Ну сколько можно.
Отмечено крсным болдом то, о чем разговор.
Как вы его вызываете то, метод ваш? В приложении - как? Если его на стадии разработки нет - как его можно вызвать?
Вас десятую страницу просят показать пример - вы упорно отказываетесь, каждый раз впадая в теорию ООП.
Неужели из моего ответа не понятно, что есть этот метод на стадии разработки?
Вам пример кода что ли нужен?
Хорошо, будет вам пример кода...
Вот код для выборки списка для того примера, который я приводил страницой раньше:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
CollectionPager pager = new CollectionPager(
new Query("OrderBase", QueryOptions.Polymorph)
.AddChildRelation(“OrderBase-OrderItem”)
.AddCriteria(new QueryCriteria("OrderBase", "UserId", "=", "@UserId"))
.AddCriteria(new QueryCriteria("OrderBase", "OrderType", "=", "@OrderType"))
.SetSort("OrderDate", SortOrder.Descending)
.AddParam(“@UserId”, UserId)
.AddParam(“@OrderType”, OrderType)
.SetPaging( 1 , PageSize)));
IOrderCollection oc = pager.Load();
…..
По объекту типа IOrderCollection происходит binding к гриду в форме списка объектов.
Метод, вызываемый обработчиком событий формы, по которому изменяется стоимость товара в Order’е
1.
2.
3.
4.
5.
6.
7.
8.
9.
protected virtual void ChangeItemPrice(IOrderBase order, Decimal price)
{
IOrderItem item = getCurrentItem();
Try
{
order.ChangeItemPrice(item.Id, price);
}
Catch (Exception ex) { ExceptionManager.WriteToLog(ex); }
}
Как видно из примера, действие ChangeItemPrice выполняется методом объекта, доступ к которому идет через интерфейс IOrderBase. Метод, из которого выполняется это действие, определен в базовой форме списка заказов/счетов/заявок. От этой формы наследуются конкретные формы списков, в которых эту операцию переопределять или реализовывать заново уже не требуется.
Только пожалуйста, не говорите опять, что вам ничего не понятно или что я вам лекцию по ООП читаю… Понятнее по-моему уже объяснить трудно. Я вообще не пойму, чего вы от меня добиваетесь на пару с тигрой (или вы одно и то же лицо? :)) Чтобы я вам привел тут документацию к системе, чтобы ее для вас разжевал? И не надо тут про коробку передач издеваться. Какой вопрос – такой и ответ. Вы сами-то можете точно сформулировать, что вам надо? Или сами толком не знаете, что вам нужно?
-----------------------------------------------------
PS. Полностью согласен с последним постом от Архитектора.
