Question

方案： X公司创建了一个大型ASP.NET应用程序。许多其他公司创建子应用程序。让我们假设~10家公司和总共约100个子申请。

子应用程序有一个有趣的要求。没有DLL可以部署到生产服务器。只能部署.ascx / .ascx.cs / .cs文件和.css / .js / image文件。

我工作的子应用程序是作为Web应用程序开发的，但是不部署DLL并使用CodeFile使其类似于Web站点。

子应用程序的部署方式如下：

.ascx和.ascx.cs文件转到：

inetpub\wwwroot\LargeSystem\layouts\CompanyName\ApplicationName\

.cs文件转到App_Code文件夹：

LargeSystem\App_Code\CompanyName\ApplicationName\

这会导致App_Code文件夹中的目录结构与此类似。

LargeSystem\App_Code\Company1\Application1
LargeSystem\App_Code\Company1\Application2
LargeSystem\App_Code\Company1\Application3
LargeSystem\App_Code\Company2\Application4
LargeSystem\App_Code\Company2\Application5
LargeSystem\App_Code\Company3\Application6
LargeSystem\App_Code\Company3\Application7
LargeSystem\App_Code\Company3\Application8
LargeSystem\App_Code\Company3\Application9
LargeSystem\App_Code\Company3\Application10
LargeSystem\App_Code\Company4\Application11
... and the list goes on.

App_Code中的所有.cs类都被编译为App_Code.dll。每次重新编译时，DLL名称都附加一个随机字符串。

我没有看到这种方法有任何好处。我没有找到任何建议在App_Code中存储所有业务逻辑的资源。但它可以做到，如果这是一个实际的要求，这种方法必须有一些好处。避免依赖性问题是我从X公司那里听到的唯一原因。

我用这种方法看到的问题：

App_Code编译需要很长时间。我不知道App_Code.dll的大小或编译时间有多长。
任何.cs文件中的编译错误都会导致App_Code.dll无法编译。我没有看到解决方法。
存储在一个DLL中的无关应用程序代码。

在App_Code文件夹中包含所有业务逻辑有哪些缺点和好处？

0 个答案: