3 ms·
I maintain a line-of-business webapp that could be mistaken for a typical CRUD app, but actually has a lot of business logic enforced in code. That's stuff you
by niftich 10y ago
I maintain a line-of-business webapp that could be mistaken for a typical CRUD app, but actually has a lot of business logic enforced in code.
That's stuff you don't have to hardcode -- you can pull it out into a 'rules engine' (at the expense of an additional runtime dependency) or push it further down into, say, database stored procedures (I can hear some of you shudder). But for us, the rules rarely change, or change at a pace that's acceptable to keep up with.
Also, there are a lot of views and specialized interfaces tailored for particular workflows. In several cases, the data underneath of them is the same, but there are different UIs -- that adds LOCs considerably.
- eru 10y agoI wouldn't draw the distinction at 'hardcode' or some alternative. Rather the question is which language expresses the business rules well enough (or even best). If your application language also does a decent job of expressing the business logic, that's great.
- huherto 10y agoI don't get the rules engine thing. It is still code. I rather have them hardcoded with proper source control and do frequent releases. May be when you have rules that change every hour back and forth.
- manacit 10y agoThe difference is, I think, that you might want to be able to ad-hoc configure the rules without changing code. Going beyond that, you might want to allow people who are not developers to add/remove/change rules around business logic. Building all of this up can be quite an effort depending on how complicated the rules get.