如何在Visual Studio中构造ASP.NET源代码?

我倾向于(但并非总是)每个作业都有一个解决方案,但是我从其他解决方案导入现有的项目,例如我的WebControlLibrary,在那里我保留公共用户控件和类等。

我的实际工作解决方案,然后我倾向于分解为Web应用程序、业务逻辑层、数据访问层和实体层,即:

Solution
...MyCompany.WebControlLibrary
...Project
...Project.BusinessLogic
...Project.DataAccess
...Project.Entities
...Project.Scripts
...Project.Testing
...Project.Deployment

如果一个项目需要像移动设备这样的东西,我总是把它放在一个新的解决方案中,但是它可能共享当前解决方案的一些项目,即。

MobileSolution
...MobileProject
...Project.Entities
...MobileProject.BusinessLogic

你组合的“东西”越多,视觉工作室的速度就越慢。显然,您可以在默认情况下停止某些项目的生成,但此时必须开始创建自己的生成配置。如果您要创建大型应用程序,我建议将其分解为多个解决方案。我发现在不断改变构建配置的解决方案之间切换更容易。

另一种选择是,在构建项目时,可以引用它们的DLL。我更喜欢将所述项目导入到我的解决方案中,因为您不必担心引用创建的构建配置,即从debug或release文件夹中选择dll。

独立库可以是它们自己的解决方案。可以将这些库的引用添加到您正在使用的项目中。Web应用程序、测试设置和特定库(如数据访问或业务规则)等相关项可以在一个解决方案中设置为项目。这真的取决于你有多想打破东西的可恢复性。

这在一定程度上取决于项目执行的工作。

为了便于使用,很容易找到一个只包含所有所需项目的解决方案。如果这是一个大的解决方案,那么稍后当IDE开始变慢,构建时间也会从屋顶飞驰而过时,这会妨碍您的工作。

假设其中一个项目是一个图书馆,你的公司使用它来支付信用卡,并与3dsecure接口。你展示了你自己的图形用户界面页面来获取细节等。

如果您有许多站点都接受信用卡支付,那么您将在一个单独的解决方案中拥有这个项目并引用编译的DLL,这将使您受益匪浅。您需要的任何更改都需要打开解决方案、进行更改、构建解决方案、转到正在使用的解决方案并进行测试。听起来像一个皮塔,你会发现把它放在一个大的解决方案中很简单。但是,如果您在每个解决方案中都有这个库,并且对它进行了一般性的更改,那么您需要一直重复这个更改。

所以你只需要决定你是在同一个解决方案中开发一个单独的项目,还是其他地方使用的项目。如果您需要比库提供的更多的功能,您可以在项目中实现一个部分类,并以这种方式扩展库。或者一个包装类就足够了。但是,您知道您不会影响其他使用此库的站点,并且在开发过程中,您可以使用较小的内存打印来保持您的解决方案更小、更易于管理。