2013-05-22 11 views
6

Zajmuję się tworzeniem aplikacji rejestracji/fakturowania w ASP.Net, z wykorzystaniem struktury podmiotu. Jeśli chodzi o generowanie rachunku dla rejestrującego, mój klient ma wiele zwodniczych kryteriów. Zamiast naliczania opłat za łóżko za noc (dość standardowy ..) klient może zostać obciążony inną kwotą w zależności od ich wieku, konkretnych dat, które odwiedzają, rodzaju pokoju (podwójne łóżko, pojedyncze łóżko itp.) Lub konferencja że oni udział, albo wszystkie cztery ...Solidny projekt systemu billingowego. Czy idę całkowicie w złym kierunku?

Oto mój schemat: http://s8.postimg.org/w8nxh8qlh/abstraction.jpg

Będąc stosunkowo młody programista, czuję się jakbym czegoś brakuje, gdzieś wzdłuż stołu „Rule”. Próbuję to zrobić, aby administrator mógł utworzyć dowolną liczbę ConditionalStatements ("Age> 5" lub "Age < 10", gdzie "Age" jest Statement.Value, "> jest Condition.Value, i "5" to ConditionalStatement.Value) i połączyć dowolną ich liczbę, tworząc "Regułę". Administrator następnie powiązałby regułę z różnymi RateSchedules, a aplikacja byłaby wtedy w stanie wygenerować rachunek dla każdego klienta, który zarejestrował się na pobyt ..

Czuję, że jestem na dobrej drodze, i że większość tego rozwiązania będzie działała w każdy możliwy sposób, ale coś jest nie tak. Mam dwa pytania dotyczące tworzenia "reguły".

  • Co robię źle, jeśli chodzi o projekt "zasady"? Wydaje mi się, że niepoprawne jest generowanie nowego RuleSet.ID za każdym razem, gdy administrator chce stworzyć nową regułę. Czy jest to coś, co powinienem programowo zaprogramować? Czy powinienem całkowicie przemyśleć ten proces Reguły?

  • Z perspektywy Entity Framework/scaffolding, jaki jest najlepszy sposób dodawania nowych reguł do bazy danych? Domyślne rusztowanie pozwala wstawiać jeden wiersz naraz, ale aby utworzyć regułę, musiałbym powiązać plik RuleSet.ID z wieloma ustawieniami warunkowymi. Nie mogę jednak znaleźć sposobu na intuicyjną interakcję z EF rusztowanie ..

Wszelkie wskazówki we właściwym kierunku są wysoko cenione! Dzięki :)

EDIT: I skończyłem przebudowy w oparciu o odpowiedzi na moje pytanie, ale w trakcie badań natknął silnik reguł biznesowych Microsoft: http://msdn.microsoft.com/en-us/library/aa561216.aspx a także matematyczne wyrażeń: http://ncalc.codeplex.com/ wszelki wypadek ktokolwiek znajdzie to pytanie w przyszłości i te linki mogą pomóc. Dzięki za pomoc!

+1

Definiowanie DSL/AST za pomocą tabel w SQL zawsze daje mi silną sprawę odgłosów heebie ... –

+0

Możesz użyć rusztowania EF, aby utworzyć złożony zestaw wpisów bez ustawiania obcych kluczy. Zamiast tego użyj właściwości nawigacji. Dodaj obiekty podrzędne do kolekcji właściwości nawigacji obiektu nadrzędnego. Po zapisaniu zmian w Kontekstach DB wszystkie klucze obce zostaną automatycznie rozwiązane przez EF. –

Odpowiedz

-1

Modelowanie domeny w bazie danych jest zwykle złą praktyką. DB powinno być szczegółem, a cała logika powinna znajdować się w kodzie. Aby to zrobić, powinieneś wykonać projekt, aby poznać wymagania klienta i stworzyć na nim domenę. Na tym etapie ich utrzymanie będzie bardzo proste.

Na przykład wyobraź sobie klasę abstrakcyjną PricingRule i wiele różnych implementacji, takich jak AgePricingRule, DatePricingRule, RoomTypePricingRule. Wtedy twój obiekt Billa może przyjąć PricingRules i zastosować je, aby uzyskać ostateczną cenę.

Ilość złożoności danych, które należy przechowywać, będzie banalna, wystarczy jedna konfiguracja dla reguł cenowych.

+0

Wiem, że to stare stare pytanie, ale nie, nie, nie, nie, nie! Domeny to klej, który utrzymuje razem bazy danych. Baza danych nie jest szczegółem, który należy opracować później. Relacje są zdefiniowane w domenach. Właściwe modelowanie relacyjne jest jeszcze ważniejsze w takim scenariuszu. –

Powiązane problemy