解决方案中的项目
我想知道如何将大规模应用程序划分为项目。 我需要创建：
1. 数据访问层一个项目。
2. 业务逻辑层一个项目。
3. 一个Web应用程序项目。
？
数据访问层和业务登录层应该放在一起吗？
另外，数据访问层是否应该依赖于业务登录层？
Web应用程序应该直接依赖于数据访问层吗？ （在使用业务登录层的对象的工作中是否应该使用数据访问层的方法）？
现在我有两个项目：
1.网络应用程序。
2.所有代码包括数据访问和业务对象。
I am wondering how divide large scale application into projects.
Does I need to create:
1. one project for the data access layer.
2. one project for the business logic layer.
3. one project for the web application.
?
should I put the data access layer and the business login layer together?
in addition, does the data access layer should depend on the business login layer?
should the web application depend on the data access layer directly? (does is should use methods from the data access layer on work using objects from the business login layer)?
right now I have two projects:
1. web application.
2. all the code including data access and business objects.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在这里下载 Microsoft 应用程序架构指南，第二版，我现在正在阅读它，它对这个主题非常有帮助：
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ce40e4e1-9838-4c89-a197-a373b2a60df2
Download Microsoft Application Architecture Guide, 2nd Edition here, I'm now reading it and it is very helpful on the subject:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ce40e4e1-9838-4c89-a197-a373b2a60df2
我通常将我的项目分开：
解决方案
-> 表示层
->业务层
-> 数据层
然后，我添加从演示文稿到业务以及从业务到数据的引用。我从不让我的演示文稿直接与数据交互。通常，我还会利用业务层中的服务，如有必要，这些服务可以部署到单独的位置。
I typically keep my projects seperate:
Solution
->Presentation Tier
->Business Tier
->Data Tier
I then add reference from Presentation to Business and Business to Data. I never let my Presentation interact directly from Data. Typically I also utilize services in my Business layer that can be deployed to separate location if necessary.
这取决于您所说的“非常大的项目”是什么意思。
我们正在编写一个 MVC 应用程序，并将其分成几个程序集……一个程序集对应我们正在访问的每个数据库。但它不仅仅是 DAL，它还有一些特殊的逻辑。该程序集还具有一些通用功能。
然后我们就有了一个共同的网络项目。
然后，我们为使用此数据的 3 个站点中的每一个站点创建一个 Web 项目，它们都依赖于公共项目。
如果将其分成至少 3 个程序集，维护和开发可能会更容易。原因如下。
It depends on what you mean by a "very large project."
We are writing an MVC application and we have split it into several assemblies... one for each of the databases we're accessing. But it's not just DAL, it's got SOME special logic in there as well. This assembly also has some common functionality.
We then have a common web project.
We then have a web project for each of the 3 sites that use this data, they all depend on the common project.
It will probably be easier to maintain and develop if you split it into at least 3 assemblies. Here's why.