用于存储配置信息(例如存储过程名称)的良好格式
在我们的应用程序数据层中,我们完全依赖存储过程和 Web 服务来进行数据交换。我们在大量页面中使用如下代码来执行存储过程,
switch(requesttype)
{
case "GetEmployees":
switch (crud_type)
{
case "read":
Execute Stored Procedure 'A'
break;
}
break;
}
我们正在寻找将上述代码(位于类文件内部)删除到某种形式的配置文件的方法
我们正在寻找能够非常快地执行的文件存储格式检索(读取、解析等)和保存(写入、修改等)
我们可以在其之上实现一个安全层
无需对现有代码进行太多大惊小怪和重大更改即可实现这一目标。
In our application data tier we completely rely on stored procedures and web services for Data exchange. We use code like below in loads of pages to execute stored procedures
switch(requesttype)
{
case "GetEmployees":
switch (crud_type)
{
case "read":
Execute Stored Procedure 'A'
break;
}
break;
}
we are looking for ways to remove above code(which is inside class files) to some form of configuration file
We are looking for file storage format that are extremely fast to retrieve(read,parse etc) and save(write,modify etc)
We could implement a security layer above it
Achieve this without much fuss and major changes to existing code.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我想我已经超前了。你不能用配置替换代码,因为代码会做一些事情,而配置只会告诉代码做什么或如何做某事(除非配置本身包含代码,在这种情况下你有一个悖论)。如果您想将可配置性应用于您的代码,您首先需要使其更加通用/通用(您的
switch
语句表明它现在不通用)。我的原始答案(如下)中描述了我这样做的方法。它本身不提供可配置性,但可以这样做(我已经相当简单地做到了)。该代码基于您原来的问题,因此请重新调整您的眼睛以正确阅读它。我过去选择的选项是使用工厂(无论是位于单例中还是以 IoC 容器的形式传递给拥有代码示例的函数。
我的方法的非常高级的实现基本上是定义一个自定义属性,其中包含一个指示您的类型何时有用的属性,例如:
以及一个提供运行代码所需的 API 的通用接口,例如:
然后您可以装饰特定的类。使用属性并实现接口来表明它们适用于每个操作:
在程序中的某个时刻,您将需要能够发现哪些类型适合哪些操作,我通过反射来完成此操作,尽管它可以通过配置轻松完成(这会击败该操作)。一些 IoC 容器提供了类似的可发现性属性,但使用其他人的属性时,您将按照自己的方式进行操作(通常),
一旦您发现哪些类型适合哪些操作,您可以使用以下内容:
基于这个设计,我倾向于只使用
App.Config
/Web.Config
来存储您的配置。无论如何,它通常都会在那里;也可以将其用于您的目的。I think I got ahead of myself. You can't replace code with configuration because the code will do something while a configuration would simply tell the code what or how to do something (unless the configuration itself contains code in which case you've got a paradox). If you want to apply configurability to your code, you'll first need to make it more general/generic (your
switch
statements indicate that it is not general now). My approach to doing this is described in my original answer (below). It doesn't provide configurability on its own, but could be made to do so (I've done it fairly simply). The code is based on your original question so please readjust your eyes to read it correctly.The option I've opted for in the past has been to use a factory (whether housed in a Singleton or passed to the function owning your code sample in the form of an IoC container.
Very high level implementation of my approach is basically to define a custom attribute which contains a property that indicates when your type is useful. Something like:
And a common interface to provide the API needed for your code to be run. Something like:
And then you decorate specific classes with the attribute and implement the interface to indicate that they are appropriate for each action:
At some point in your program you will need to be able to discover which types are appropriate for which actions. I do this with reflection, though it could just as easily be done with configuration (which would defeat the point of the attribute). Several IoC containers provide similar discoverability attributes, though using someone else's you'll be left doing things their way (typically).
Once you've discovered which types are appropriate for which actions, you can use something like:
Based on this design I would lean towards just using the
App.Config
/Web.Config
to store your configuration. It'll generally be there anyway; may as well use it for your purposes as well.