Design Hints, Payroll System ... репост

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

Answer 2

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

Вопросы безопасности, которые вам действительно необходимо учитывать при расчете заработной платы: Нигде не используйте динамический sql. Ни один пользователь не должен иметь прямых прав на таблицы. Все права должны быть на уровне sp (и никаких динамических sql в sps либо вы не должны устанавливать права на уровне таблицы). Это ограничивает возможности пользователей совершать мошенничество с платежной ведомостью и является чрезвычайно важным. Любая система начисления заработной платы, использующая любой динамический sql, подвергается риску для сотрудников компании совершить мошенничество, напрямую обращаясь к таблицам и выполняя действия, которые приложение не позволяет им делать. Это одна из причин, почему я бы не принял никакого ответа на ваш вопрос, кроме как использовать sps.

Бизнес-правила должны применяться на уровне базы данных по той же причине. Вы не хотите, чтобы кто-то, используя инструмент запросов, добавил или изменил данные, которые не соответствуют вашим бизнес-правилам. Это чрезвычайно важно для расчета заработной платы (или любой другой финансовой системы). Используйте ограничения, где это возможно, срабатывает, если логика более сложная.

Вам необходимо проверить все таблицы, включая записи о том, кто и когда внес изменения в данные.

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

Answer 3

Зависит от того, сколько точек принятия решения у вас есть в алгоритме. И сколько изменений вы ожидаете.

Подход all SP, вероятно, даст вам наилучшую производительность, если ваша обработка будет равномерной. Это позволит вам в полной мере использовать преимущества кэшей базы данных и избежать узких мест в сети. Остерегайтесь курсоров и запросов с критериями соединения, отличными от равных / не равных (если они у вас есть, обработка обычно лучше обрабатывается языком общего назначения).

Если вы обращаетесь к приложению, рассмотрите возможность использования системы управления правилами для кодирования правил вне базы данных. Это даст вам максимальную прозрачность и гибкость. Хорошие бесплатные движки правил для Java - это Drools (некоторым людям также нравится Джесс, который является клоном CLIPS). Не уверен, что такое .Net предложения, но в худшем случае вы можете обернуть Drools в веб-сервис и использовать его из C #.

Answer 4

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

Почему бы не объединить лучшее из обоих? то есть разделить логику на отдельные компоненты, записанные как SP, вызываемые из основного SP?

Это все обработка данных, зачем использовать «прикладной уровень», кроме вызова основного SP?

Answer 5

Может быть, вы хотите проверить Agile Принципы, Шаблоны и Практики в C # Основной пример в книге - разработка гибкой системы начисления заработной платы ....