是否有针对 ASP.NET MVC 生产应用程序的建议解决方案结构
一般来说，我不喜欢将代码（基类或数据访问代码）保留在 ASP.NET 站点的 App_Code 目录中。我通常会将这些内容提取到 MySite.BusinessLogic & 中。分别是MySite.DataAccess DLL。
我想知道我是否应该对 ASP.NET MVC 做同样的事情。
沿着
- MySite.Common - DLL - （基于 .NET 系统 Dll 的基本功能）
- 组织解决方案会更好吗MySite.DAL - DLL - （DataAccessLayer 和 DBML 文件）
- MySite.Models - DLL - (MVC模型，例如存储库类）
- MySite.Controllers - DLL（使用模型的 MVC 控制器）
- MySite - ASP.NET MVC 站点。
或者我错过了一些东西......大概，我会失去一些好的东西（添加视图，转到控制器，已添加的上下文菜单项）
In general, I don't like to keep code (BaseClasses or DataAccess Code) in the App_Code directory of an ASP.NET Site. I'll usually pull this stuff out into a MySite.BusinessLogic & MySite.DataAccess DLL's respectively.
I'm wondering should I be doing the same for ASP.NET MVC.
Would it be better to Organise the solution something along the lines of
- MySite.Common - DLL - (Basic Functionality built on .NET System Dlls)
- MySite.DAL - DLL - (DataAccessLayer & DBML Files)
- MySite.Models - DLL - (MVC Models e.g. Repository Classes)
- MySite.Controllers - DLL (MVC Controllers which use Models)
- MySite - ASP.NET MVC Site.
Or am I missing something... presumably, I'll lose some of the nice (Add View, Go To Controller, context menu items that have been added)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我只使用 MVC 完成了几个项目，但使用您的命名结构，我们执行了以下操作：
DBML 文件和存储库模型）
MVC Web 应用程序的一部分，并且只有
特定于视图的模型没有
始终将每个映射一对一
存储库模型。
MVC 应用程序，但可以链接到业务层
因此，最终我的 MVC 解决方案中有以下项目：
编辑：我的 DAL 始终输出包装对象（如果使用 Linq2Sql，那么我将自动生成的类直接映射到 DAL 中的类）。 MVC 应用程序中存在的唯一类是表示视图的容器，主要用于将数据传递到视图。
如果您的移动应用程序使用类似的视图，我不会尝试重复使用 MVC 应用程序视图中的相同类。您总是需要管理一些细微的差异，并且您应该能够仅使用 DAL 类来映射到您的移动视图，该视图遵循将视图类本地化到应用程序的模式。
I have only done a few projects using MVC but using your naming structure we did the following:
DBML Files and Repostiory Models)
of the MVC web app and only had
models specific to views that did not
always map one to one for each
repository model.
of MVC app but could link to a Business Layer
So in the end had the following projects in my MVC solution:
EDIT: My DALs alway output wrapped objects (if using Linq2Sql then I map the autogenerated classes to my classes in the DAL directly). The only classes that exist in the MVC app are containers that represent the viwes and mainly used to pass data to the views.
If your mobile app is using similar views I wouldn't try and re-use the same classes from your MVC app views. There is always slight differences that you will need to manage and you should be able to just use the DAL classes to map to your mobile views which follows the pattern of keeping the view classes localized to the app.
在大多数情况下，以下结构工作正常：
MySiteA 和 MySiteB 可能是同一站点的两种形式，重用业务逻辑中的功能。
从性能角度来看，与许多小型组件相比，您应该更喜欢较少的大型组件。
In most cases the following structure works fine:
MySiteA and MySiteB might be two flavors of the same site reusing functionality from the business logic.
From performance perspective you should prefer fewer larger assemblies than many small assemblies.
我们做的事情有点不同
我们这样做是因为我们有多个连接的数据库和数据服务。根据问题域的不同，同一数据库可能会使用不同的模型集进行访问，但有时共享相似的名称。
在服务模块中，我们将具有以下结构
We do things a bit different
We do this because we have multiple databases and data services that we connect to. And depending on the problem domain the same database might be accessed with a different set of models but sometimes sharing similar names.
Within a Services module we'll have the following structure