Надежный дизайн биллинговой системы. Я иду совсем не в том направлении?
Я разрабатываю приложение регистрации отеля / выставления счетов в ASP.Net, используя Entity framework. Когда дело доходит до создания счета для регистратора, у моего клиента есть много дурацких критериев. Вместо кровати за ночь (довольно стандартный..) биллинговой системы, клиенту может быть выставлен счет различные суммы, основанные на их возраст, даты пребывания, тип номера (двуспальная кровать, односпальная кровать и т. д.) Или конференции, которые они посещают, или все четыре...
вот моя диаграмма:
будучи относительно молодым кодером, я чувствую, что мне чего-то не хватает, где-то в таблице "правил". То, что я пытаюсь сделать, это позволить администратору создать любое количество ConditionalStatements ("Возраст > 5" или "возраст " - это условие.Значение, а " 5 " - это условное обозначение.Value) и связывают любое их количество вместе, создавая тем самым"правило". Тогда администратор свяжите правило с различными RateSchedules, и приложение будет иметь возможность генерировать счет для любого клиента, который зарегистрировался для пребывания..
Я чувствую, что нахожусь на правильном пути, и что большинство этого решения будет работать так, как мне нужно, но что-то не кажется правильным. У меня есть два вопроса, касающиеся создания "правила"..
Что я делаю неправильно, насколько" правило " дизайн идет? Это чувство ... не для меня. создание нового набора правил.ID каждый раз, когда администратор хочет установить новое правило.. Это то, что я должен делать программно? Должен ли я полностью переосмыслить этот процесс правил?
с точки зрения Entity Framework / scaffolding, каков наилучший способ добавления новых правил в БД? Леса по умолчанию позволяют вставлять по одной строке за раз, но чтобы создать правило, мне нужно связать набор правил.ID с несколькими ConditionalStatement.IDs - но я не могу понять, как сделать это интуитивно с помощью EF scaffolding..
любой указатели в правильном направлении высоко ценится! Спасибо :)
EDIT: Я закончил редизайн на основе ответов на мой вопрос, но во время исследования наткнулся на механизм бизнес-правил Microsoft: http://msdn.microsoft.com/en-us/library/aa561216.aspx а также математическое выражение оценщик: http://ncalc.codeplex.com/ На всякий случай, если кто-то еще найдет этот вопрос в будущем, и эти ссылки могут помочь. Спасибо за помощь ребята!
1 ответов
моделирование вашего домена в БД обычно является плохой практикой. БД должна быть детализированной, и вся ваша логика должна быть в коде. Чтобы сделать это, вы должны сделать дизайн, чтобы выяснить требования клиента и создать домен на вершине, что. На этом этапе настаивать на них будет очень просто.
например, представьте абстрактный класс PricingRule и множество различных реализаций, таких как AgePricingRule, DatePricingRule, RoomTypePricingRule. Тогда ваш объект Bill может принять PricingRules и применять их и получить окончательную цену.
объем сложности данных, которые необходимо сохранить, будет тривиальным, просто некоторая конфигурация для правил ценообразования.