Комментарии 4
А где собственно «проектирование системы учета товаров»? То, что вы автоматизировали одну из операций (выдачу покупателю), хоть даже и со счетчиком ну совсем не тянет на систему учета.
Система учета товара тут скрыта где-то за серверным скриптом.
А об этом счетчике вопросов вообще много. Зачем он? Вроде как похож на идею контроля ненулевого остатка, но это проверять надо ДО попытки выдачи чего-то. А тут мы уже в событии После. Зачем условие GoodsCounter>0 ограничивает уменьшение счетчика? Товар клиенту отдали, а уменьшение количества товара регистрировать отказались?
Система учета товара тут скрыта где-то за серверным скриптом.
А об этом счетчике вопросов вообще много. Зачем он? Вроде как похож на идею контроля ненулевого остатка, но это проверять надо ДО попытки выдачи чего-то. А тут мы уже в событии После. Зачем условие GoodsCounter>0 ограничивает уменьшение счетчика? Товар клиенту отдали, а уменьшение количества товара регистрировать отказались?
Смотрите: здесь под проектированием понимается очерчивание общих рамок системы. В другом случае, это была бы история про «детальный разбор существующей или полностью спроектированной системы». Так как каждая конкретная реализация будет иметь свои нюансы, и соответственно разную архитектуру (в целом или в частностях). В данном случае, система достаточно простая и вполне может выполнять, при соответствующих доработках, озвученную функцию: учет количества определенного товара в ячейке/ячейках и оперативное информирование центрального офиса.
Собственно именно для этого и предназначен счетчик. По поводу срабатывания ПОСЛЕ события: так как «событием» в самом простом случае (когда рядом с ячейкой нет никаких мониторов, извещающих о количестве в ячейке) является физическое открытие ячейки – поэтому срабатывания счетчика происходит после события.
Если необходимо срабатывание ДО – нужно усложнять схему выводом предварительного отображения количества рядом с ячейкой.
Собственно именно для этого и предназначен счетчик. По поводу срабатывания ПОСЛЕ события: так как «событием» в самом простом случае (когда рядом с ячейкой нет никаких мониторов, извещающих о количестве в ячейке) является физическое открытие ячейки – поэтому срабатывания счетчика происходит после события.
Если необходимо срабатывание ДО – нужно усложнять схему выводом предварительного отображения количества рядом с ячейкой.
«Зачем условие GoodsCounter>0 ограничивает уменьшение счетчика?»Так как количество товаров в ячейке не может быть равным «-1». Поэтому и условие уменьшения товара работает только в случае, если минимальное число товаров равно 1. (1-1=0. «Ячейка пуста»).
«Товар клиенту отдали, а уменьшение количества товара регистрировать отказались?»Регистрация происходит в строке 24, когда срабатывает функция ToDataBaseLoader (), отправляющая состояние глобальной переменной (GoodsCounter) – в базу данных, с помощью метода POST.
Так как количество товаров в ячейке не может быть равным «-1». Поэтому и условие уменьшения товара работает только в случае, если минимальное число товаров равно 1. (1-1=0. «Ячейка пуста»).
Нет, эта мысль то понятна. Зачем это делать? Т.е. если вы хотите контроль отрицательного сделать в этой железке и не давать покупателю товар, то поздновато уже (не то событие).
Уместность этого контроля тоже под вопросом — если сработало событие выдачи, то физически товар выдали покупателю (и он физически был). Многие предприниматели приходят к правилу, что раз товар физически есть, то его стоит продать сейчас, а с неправильным состоянием системы (в данном случае счетчик в минус уйдет) разбираться уже после. Разбор таких ситуаций чаще всего приводит к ошибке в оформлении прихода товара.
Зачем контроль располагать именно в этой железке?
Опять же, если вы делаете приложение, которое требует постоянного онлайна с учетной системой и общается с ней в синхронном режиме (ToDataBaseLoader() на каждом событии), то в той системе же можно и хранить остатки товаров этого автомата по ячейкам и у нее же спрашивать, достаточно ли остатка для выдачи.
Имхо, переносить логику контроля сюда оправдано только при асинхронном режиме обмена. Когда ToDataBaseLoader() не блокирует выполнение, а отправляем данные в другом потоке или складывает их в очередь и отправляет раз в какое-то время пакетом.
По поводу запроса данных с сервера, — да вполне можно и так сделать, ваш подход здравый.
Почему был сделан «учет в железке»: основная мысль заключалась только в том, чтобы устранить критическую зависимость от качества сети, для осуществления операции выдачи. То есть внешняя база в офисе, в данной схеме служит только «представительским» целям, чтобы торговый представитель примерно понимал (особая точность даже не требуется), сколько товара (+-) нужно завезти в эту точку и когда. Потому что лично приходилось сталкиваться с разного рода «глушилками» связи при встречах важных людей и прочими неожиданными ситуациями.
Почему был сделан «учет в железке»: основная мысль заключалась только в том, чтобы устранить критическую зависимость от качества сети, для осуществления операции выдачи. То есть внешняя база в офисе, в данной схеме служит только «представительским» целям, чтобы торговый представитель примерно понимал (особая точность даже не требуется), сколько товара (+-) нужно завезти в эту точку и когда. Потому что лично приходилось сталкиваться с разного рода «глушилками» связи при встречах важных людей и прочими неожиданными ситуациями.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проектирование простой системы учёта товаров на небольшом складе