Цитата:
Сообщение от
mazzy
чтобы красиво использовать SaleLast c this, нужно переопределить четыре метода (или предоставить четыре параметра).
В исходной постановке ведь говорится про объект packable, а не про this - для packable можно сделать вспомогательный класс, который будет реализовывать нужные методы SysSaveable, а на вход получать некий идентификатор плюс SysPackable-объект, который уже собственно паковать либо распаковывать вместо себя. Не знаю, правда, насколько такая реализация будет считаться "красивой".
Цитата:
Сообщение от
mazzy
SaveLast записывает данные в контейнер, следовательно никаких индексов по содержимому. А также ограничение на размер сохраняемых данных (сложности с передачей больших контейнеров).
SaveLast записывает контейнер с данными как одно memo-поле, которое в SQL не пришей кобыле хвост. А можно записывать каждое значение контейнера как отдельную запись в SQL, все записи одного SaveLAst должны получить некий идентификатор сессии. Так можно получить поиск по содержимому.
Ну вот, начали с клиент-серверной передачи объектов, а пришли к поиску по содержимому объектов в базе SQL
Напомнило один анекдот:
Цитата:
- Слушай, ты разработчик. Ответь, почему разработчики всегда неправильно оценивают время на создание программ?
- Представь что тебе надо разгрузить машину, сколько времени это займет?
- Пару часов
- Это камаз
- 8 часов
- Камаз, груженый песком
- 12 часов
- У тебя нет лопаты и инструментов, только твои руки
- 2 дня
- На улице -40
- 4 дня
- Камаз вообще под водой
- Так же нечестно, ты постоянно придумываешь новые условия! К чему ты мне вообще все это рассказываешь? Вы, разработчики, вечно всякую фигню рассказываете! Вместо этого могли бы просто оценить правильное время на разработку.
Цитата:
Сообщение от
mazzy
Я удивлен, но не увидел обсуждения стандартных классов по передаче файлов между клиентом и сервером SysFileDeploy
У меня лично был
весьма негативный опыт его использования
Цитата:
Сообщение от
mazzy
AifWebReferenceUtil (второй умеет как с клиента на сервер, так и с сервера на клиент).
А он точно был в версиях "ax3,ax4", которые упоминаются в исходном вопросе?
Цитата:
Сообщение от
mazzy
как способ взаимодействия между клиентАМИ и серверАМИ можно рассмотреть запись в AOT\resource.
Это те ресурсы, которых не было в старых версиях, а в ax2012 они - свои на каждом АОСе с его локальным CIL, да? И вообще, писать в приложение (design-time) что-либо для каждодневной работы конкретной инсталляции (runtime) - это моветон, как по мне. Тем более в последних версиях и не осуществимый.
Цитата:
Сообщение от
mazzy
если честно, то я скорее ожидал увидеть развитие темы в сторону клиентских и серверных кэшей. И ограничения этих способов.
Т.е. в одном случае предлагается резать контейнер на части, чтобы обойти ограничение на размер пакета в ax4/ax2009/ax2012, а в другом случае предлагается просто закрыть глазки ладошками и представить, что этих ограничений нет? Пускай, мол, среда времени выполнения абстрагирует нас на вставке в кэш
на другой стороне от того, что есть какие-то там RPC и какие-то там
maxbuffersize в настройках...
Цитата:
Сообщение от
mazzy
Отлично понимаю, что способ передачи файла - не идеал. Но красоту поискать можно. Можно и посравнивать с другими способами.
Такое ощущение, что вместо решения практической задачи идет составление опросника для собеседования.
Как там у Джоэла Спольски?
Цитата:
Каким бы превосходным C++ кодировщиком ни был человек без опыта в API, он знает только около 10% того, что он должен использовать каждый день для написания кода запускаемого на API. Когда дела в экономике идут хорошо, это не имеет значения. Вы все еще имеете работу и наниматели платят стоимость вашего обучения соответствующей платформе. Но когда в экономике царит неразбериха и 600 человек подают заявления на каждую открытую вакансию, наниматели могут позволить себе удовольствие выбирать программистов которые уже эксперты в интересующей их области. Например, программистов, которые могут назвать четыре способа заслать файл по FPT из кода на Visual Basic и слабые и сильные стороны каждого из них.