数据驱动的状态机应用
我们目前正在开发“数据驱动”状态机应用程序。 现在，状态流都在数据库中配置，但在我们当前的设计中，没有任何决策/业务逻辑可以在数据库中配置。 因此，代码基本上也必须“了解”状态流，因此在数据库中配置流确实没有意义。
我心中有一个设计，允许我们使用依赖注入（Spring.NET）将状态模式连接在一起，但我不确定实现数据驱动的最佳方法。 我不太喜欢在数据库中配置类似代码的东西（例如类或方法名称），但我想到的设计需要我们在数据库中连接应用程序（类似于在 Spring XML 中连接）文件），所以这看起来很糟糕。
我们已经研究过使用 Windows WF，但我认为我们有点担心 WF 的未来，以及现在是否是采用它的好时机。 我从未处理过规则引擎，所以我想知道这在这里是否有用。 有人对如何实施这个有任何建议吗？
We are currently working on a "data-driven" state machine application. Right now, the state flows are all configured in the database, but none of the decision/business logic is configurable in the DB with our current design. Because of this, the code has to basically "know" the state flow as well, so there's really no point in configuring the flow in the database.
I have a design in mind that would allow us to wire together a state pattern using dependency-injection (Spring.NET), but I'm not sure of the best way to make this data-driven. I'm not a big fan of configuring code-like things (like class or method names) in the database, but the design I have in mind would require us to wire up the application in the DB (similar to wiring in a Spring XML file), so that seems bad.
We've investigated using Windows WF, but I think we're a little concerned about the future of WF, and whether this is a good time to adopt it. I've never dealt with rules engines, so I'm wondering if that might be of some use here. Does anyone have any suggestions on how to implement this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最好的选择可能是将数据存储的行为与用于实现它们的技术分离。
实现这一点的方法是 DSL（领域特定语言）。 提出一种可以抽象地表示业务逻辑的格式（即微语言），将其字符串存储在表中，并在代码中实现它的解释器。 这样，如果您的底层技术发生变化，您只需重新实现解释器。
我在 20 世纪 80 年代中期开发了一个使用此技术的应用程序，并且它已经被移植了多次，只需要对所需的业务规则进行较小（且可自动化）的更改。
Your best bet is probably to decouple the data-stored behaviors from the technology used to implement them.
The way to do this is a DSL (domain specific language). Come up with a format that can represent the business logic in the abstract (i.e. a micro language), store strings of that in your tables, and implement an interpreter for it in code. That way, if your underlying technology changes you just have to reimplement the interpreter.
I worked on an application that used this technique in the mid 1980's, and it's been ported several times with only minor (and automatible) changes to the business rules required.
有关特定于域的语言支持，请参阅MSDN 中。 您还可以查看 Irony 但这可能还不是高效代码的解决方案。
For domain specific language support look here in the MSDN. You may also have a look at Irony but this is probably not yet a solution for productive code.