c# – 将大量脚本作为嵌入式资源包含在项目中是不是一种坏习惯?

前端之家收集整理的这篇文章主要介绍了c# – 将大量脚本作为嵌入式资源包含在项目中是不是一种坏习惯?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在设计一个Visual Studio项目,它将使用各种类型的潜在大量(最多约300个)脚本文件.这些文件不会与其他项目共享,即它们是项目专有的.是否有任何好的论据反对将所有这些文件包含为嵌入式资源(通过设置它们的构建操作),然后使用Assembly.GetManifestResourceStream()在运行时检索它们?或者这是否会滥用嵌入式资源,而应该使用将这些资源作为文件保存的文件系统目录?

使用嵌入式资源的好处似乎是:

>生成的程序集易于共享和部署(单个文件部署,无需担心丢失脚本文件或无效路径);
>隔离和便利:可以从VS项目中访问所有资源.

反对这种方法的论据通常是:

>如果不重新编译和重新部署程序集,则无法修改资源.但是,即使对于具有许多基于文本的资源的项目,生成的程序集也会相当小,并且像重写一样容易重新部署,例如,一个位于文件系统的脚本文件.理论上,应该可以只更换程序集的更改部分(因此更小的更新),但我不知道是否存在任何此类现有的差异/合并工具.
>生成的DLL会更大,最终可能会更大;但是,如果您创建了没有嵌入资源的精简装配,并且将资源单独部署到目录,那么要部署的程序的总大小将是相同的.

还有其他考虑因素吗?更一般地说,是否有一个原因是项目资源 – 不管它们是什么 – 不应该作为嵌入资源包括在内,除了在修改时需要的程序集重新编译?

解决方法

我可以从复杂的环境角度给你一些见解.

如果您的应用程序对您的组织而言至关重要或重要,并且您需要最小化事件响应时间,那么将所有脚本作为单独的文件当然更好.尽管重新编译程序集可能非常容易,但在结构化企业环境中,即使在紧急情况下,修补程序版本通常也需要大量的环节.此外,这需要一个开发人员,而支持人员应该足以改变脚本文件.

其他考虑因素可能是(如果(至少某些)脚本在从资源流式传输时无法正常运行).他们可能需要一个地方来编写中间数据或结果数据.脚本之间可能还存在一些依赖关系(一个调用另一个等)

另一个因素是,当您无法访问项目源时,将资源分开可以快速查看.这为您的应用程序增加了一些透明度(可能需要或不需要).如果出现问题,可能有助于确定应用程序发生的情况,并可能进行快速更改/修复(有点类似于我的第一点).

一般来说,我会说这取决于您的要求.如果您需要能够频繁更改脚本(或其他不可编译的资源),那么将它们分开会更好.如果它们不经常更改并且您希望具有整洁,简单和紧凑的文件结构,那么嵌入是一个不错的选择.

原文链接:https://www.f2er.com/csharp/100492.html

猜你在找的C#相关文章