设计模式 - 使用一项服务从另一项服务逻辑地获取/释放资源
我有一项服务,它提供对数据库的访问。该服务由多个应用程序使用。 其中一个应用程序需要特殊功能。应该只有一个(管理)用户,可以同时操作数据。该应用程序还与其他服务进行通信。我想用两种方法扩展第二个服务的功能:
bool Acquire()
1. Check if an other user currently holds ownership.
1.1 if true => return false (acquirement failed).
1.2 if false => proceed.
2. set ownership to client connection at server side.
3. return true.
void Release()
1. Check if the client connection currently holds ownership.
1.1 if true => remove ownership of client connection at server side.
1.2 if false => do nothing.
我的问题是:这是一个好的设计模式吗?在我看来,我不应该仅仅为了一种特殊的应用需求而改变数据库服务。
I'm having a service, which provides access to a database. This service is used by multiple applications.
One of that applications needs special functionality. There should only be only one (administrative) user, which can manipulate data simultaneously. This application also communicates with an other service. I want to extend the functionality of this second service with two methods:
bool Acquire()
1. Check if an other user currently holds ownership.
1.1 if true => return false (acquirement failed).
1.2 if false => proceed.
2. set ownership to client connection at server side.
3. return true.
void Release()
1. Check if the client connection currently holds ownership.
1.1 if true => remove ownership of client connection at server side.
1.2 if false => do nothing.
My question is: Is this a good design pattern? In my opinion, I should not change the database service for only one special application requirement.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
同意,这听起来像是一个有漏洞的抽象。我认为将其转化为安全/授权问题会更合适。
定义一个特殊的安全令牌,一次只能授予一个用户。
现在,您可以在数据访问网关周围创建一个装饰器来检查是否特定的安全令牌是当前安全上下文的一部分。
通过将关注点分离到单独的类中,您可以忠实于 SOLID 原则。
Agreed, this sounds like a leaky abstraction. I think it would be more appropriate to turn this into a security/authorization problem.
Define a special security token that can be granted to only one user at a time.
Now you can create a Decorator around your data access Gateway that checks whether that particular security token is part of the current security context.
By separating concerns into separate classes you stay true to the SOLID principles.