MVC 是否会取代传统手动创建的 BLL？
我习惯于手动创建 UI、BLL、DAL（有时我使用 LINQ-to-SQL 或 SubSonic 作为 DAL）。自从 MVC 发布以来，我已经使用它完成了几个小项目。
在这些项目中，我仍然继续手工编写 BLL 和 DAL，然后将它们合并到 MVC 的模型/控制器中。我正在寻求优化我在项目上的时间，这似乎有点矫枉过正，而且可能浪费时间。
问题
滚动 DAL（例如 SubSonic）并直接在我的 MVC Web 应用程序的模型/控制器中使用它是否可以接受？现在的模型和控制器将充当 BLL。我只是认为这可以节省大量时间，而不必担心另一层。
更新：
我只是想补充一点，我真正关心的并不是 DAL（我经常使用 SubSonic 和 NH），而是关注 BLL。抱歉造成混乱。
I'm used to creating the UI, BLL, DAL by hand (some times I've used LINQ-to-SQL or SubSonic for the DAL). I've done several small projects using MVC since its release.
On these projects I've still continued to write a BLL and DAL by hand and then incorporate those into the MVC's models/controllers. I'm looking to optimize my time on projects this seems like overkill and a potential waste of time.
Question
Would it be acceptable to roll a DAL such as SubSonic and directly use it in the Models/Controllers of my MVC web app? Now the models & controllers would act as the BLL. I just see this as a major timesaver to not have to worry about another tier.
UPDATE:
I just wanted to add that my concern isn't really with the DAL (I frequently use SubSonic and NH) but rather focus on the BLL. Sorry for the confusion.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
MVC 与 n 层架构没有或很少有联系。它属于UI层，用于处理与用户的交互。如何构建应用程序的其余部分是...让我们使用“正交”这个词来判断您是否使用 MVC。
如果您有业务逻辑层，则保留它。
如果您有数据访问层，则保留它。
控制器不应该用于实现业务逻辑。它基本上是一个路由层，用于决定调用什么操作、重定向到什么路由。一般建议是保持其精简，并让它根据路由数据和一些业务逻辑调用做出决定。
此外，模型并不等于业务对象。模型是由视图显示的一组数据，可能包含一些与业务实体无关的辅助数据。
您可以使用 ORM 并用它替换数据访问层。取决于 ORM 如何集成它。通过 EF，您可以直接使用实体作为业务对象。
MVC has no or little connection to the n-tier architecture. It belongs to the UI layer and serves to process interaction with the user. How you structure the rest of your application is... let's use the word orthogonal to you using MVC or not.
Business logic layer stays if you had it.
Data access layer stays if you had it.
Controllers should not be used to implement business logic. It's basically a routing layer to decide what action to invoke, what route to redirect to. A general recommendation is to keep it thin and have it take a decision on the basis of the route data and a few business logic calls.
Also models do not equal business objects. Models are a pack of data to be displayed by a view, likely to contain some auxiliary data not related to a business entity.
You can use an ORM and replace the data access layer with it. Depends on the ORM how you can integrate it. With EF you can use the entities directly as business objects.
对于如何构建应用程序，没有一种完美的解决方案。你必须考虑具体情况并采取务实的态度。对于小型应用程序来说，架构远没有对于严肃的企业级应用程序那么重要。如果您认为您的方法将为您节省大量时间并满足您现在和将来的需求：那就去做吧。
There is not one perfect solution for how an application should be structured. You have to take into consideration the context and be pragmatic about it. For small applications architecture is far less important than for serious enterprise level applications. If you think your approach will save you a lot of time and will meet your needs now and in the future: go for it.
不，MVC 不会取代手动创建的 UI、BLL、DAL。
您不应该在大约 - 嗯 - 8 年左右的时间内手动创建 DAL。许多好或坏的 DAL 生成器已经淘汰很多年了。我在 2001 年左右发布了一个完整的 ORM。NHibernate 也已经发布很多年了。这个世界 - 即使对于 .NET - 也不会止于 MS 产品（该领域的所有产品，LINQ2SQL 和 EF）与其他产品相比质量仍然很低。
您仍然必须在 MVC 中编写业务逻辑和 UI - 只是采用与经典 ASP.NET 不同的方式。这个想法并不是要摆脱它们，而是将它们放在不同的组织中，这对于干净的 HTML 以及单元测试等更好（这在传统的 ASP.NET 中确实很难做到）。
No, MVC does not replace a manually created UI, BLL, DAL.
You should not have had a manually created DAL for about - hm - 8 years or so. Lots of good or bad DAL generators are out since many many years. I had one complete ORM out around 2001. NHibernate is out for many many years now, too. THe world - even for .NET - does not end at MS offerings (which - all of them in this area, LINQ2SQL and EF) are still really low quality compared to the stuff others have out.
You still have to code business logic and UI in MVC - just in a different fashion than with classic ASP.NET. THe idea is not getting rid of them, it is about having them in a different orgianzation which is better for clean HTML as well as, for example, unit testing (which is really hard to do in classical ASP.NET).