Проектирование системы расчета заработной платы, бизнес-логика в SP или прикладном уровне (C # .Net), ремонтопригодность - репост

Question

Мы разрабатываем систему генерации заработной платы для клиента.

Организация, на которую мы нацелены, имеет следующую иерархию: Компания -> Кластер -> Бизнес-единица (БУ) -> Отдел -> Сотрудник

Заработная плата работника состоит из различных компонентов заработной платы. У каждого компонента зарплаты есть 3 правила, связанные с ним, Правило расчета (рассчитать компонент как% от другого компонента, или% от фиксированного числа или фиксированного числа), Правило соответствия (имеет ли право сотрудник / отдел для компонента) и правило ограничения, ограничивающее максимальные и минимальные значения компонента.

**** Эти правила доступны для редактирования и могут редактироваться конечным пользователем **. Также эти правила наследуются сверху вниз, но если они определены на более низком уровне, правило более низкого уровня имеет приоритет. **

У нас есть база данных, в которой есть таблицы посещаемости, листьев, бонусов, и эти правила также должны взаимодействовать с этими таблицами.

Клиент будет генерировать платежную ведомость для нескольких клиентов, на каждом из которых будет размещен экземпляр отдельной базы данных. Каждый из них может иметь различную интерпретацию каждого компонента и может иметь разные компоненты.

Мы рассчитываем только на поддержку SQL Server, и создание платежной ведомости будет автономным действием.

Мы разделены на том, куда поместить логику, которая использует эти правила для генерации отдельных компонентов налога (которые будут включать налоговые вычеты, налоговые списания, льготы и т. Д.). Некоторые люди защищают магических SP, которые берут идентификатор сотрудника и генерируют заработную плату за этот месяц. Другие хотят, чтобы логика была разделена на отдельные компоненты, которые будут получать зависимые данные для сотрудника на прикладном уровне и вычислять эти компоненты там.

Порядок наших приоритетов: 1. Возможность быстро адаптировать изменения к новым клиентам 2. Долгосрочная ремонтопригодность 3. Производительность

1 и 2 перевешивают 3 здесь в значительной степени, так как это будет автономная деятельность.

Очень важны ремонтопригодность и быстрая настройка, мы будем развертывать приложение для разных клиентов. Клиент А может иметь Правило Компонента Зарплаты как ((0,3 * Базовый) + 800) и клиент B как (0,2 * базовый) + (0,1 * бонус за посещение)

Будет ли SP вызывать здесь беспорядок, так как правила, предложенные выше, будут определены конечным пользователем и должны будут настраиваться через веб-интерфейс. Придется разбирать формулы из SQL. Насколько это будет сложно или легко? Какое преимущество будет иметь это на уровне приложений (C # .Net) по сравнению с использованием SP?

Оригинальный пост здесь: Design Hints, Система начисления заработной платы ... repost ... но ни на один из вопросов не было дано правильного ответа.

Предложения и ссылки на архитектуру существующих систем будут очень полезны. ... и да, мы используем LINQ to SQL в других местах системы.

С уважением, Ашиш Шарма

Answer 1

Я всегда стараюсь уклоняться от размещения бизнес-логики на уровне БД. Сложнее писать, отлаживать и поддерживать. Кроме того, БД, как правило, самый дорогой слой для масштабирования. Если вам в конечном итоге понадобится улучшить свою систему для поддержки большего количества пользователей, это сравнительно дешево и легко добавить новые веб-серверы в систему, но добавление экземпляров БД становится дорогостоящим, поскольку каждая БД требует лицензии и дополнительной поддержки.

Answer 2

Вы слышали о выборах или делегатах?

Answer 3

Если вы ищете решение .Net, которое будет оценивать формулы, представленные в строках, здесь есть отличная статья, в которой подробно описываются ANTLR и C # для создания механизма вычислений. Существует полностью функциональный интерпретатор формул, который анализирует строки, строит AST, а затем оценивает выражение. Кроме того, механизм расчета реализован с использованием шаблона «Посетитель», поэтому, если у вас есть функции, которые вы хотите выполнить, например, поиск в базе данных, вы можете легко включить настройку в свое решение.

Answer 4

Если вы храните формулы, как, например, в JEP (для Java), это не является большой проблемой. Просто сохраните полную формулу в виде строки: т.е.: "pay = ((0.3 * Basic) + 800), а затем разберите ее на дерево.

Вы можете посмотреть некоторую документацию jep для информации и взять идеи оттуда. Не должно быть проблематично реализовать простые решатели для формул, которые вы разместили здесь.

Мое предложение:

• Хранить в виде строки в базе данных
• Создать небольшую библиотеку для eval и парсера.
• Разобрать его в двоичное дерево. (например, «+» указывает на 800, а также указывает на «»), затем «» указывает на «базовый» и «0,3»
• После этого вам просто нужна простая рекурсивная функция для ее решения.

Если сложность этих формул невелика, вы можете сделать это с любой стороны, которую захотите, поскольку вам не потребуется много времени для ее обработки.