Sea*_*anX 5 asp.net-mvc design-patterns n-tier-architecture
我将很快设计几个Web应用程序.它们可能会在asp.net mvc中完成.
在我在delphi中完成的现有Web应用程序中,数据访问层被分隔成一个完全独立的应用程序,有时在不同的服务器上运行.对于代码重用而言,这比结构原因更多.这不会是下一个应用程序的一个因素,因为它将是全新的.
在mvc应用程序中有单独的数据访问应用程序是否过度杀伤？我将通过使用MVC将业务类分离出来,并且我将使用ORM来执行数据库持久性.
编辑:只是为了澄清; 我使用术语"层"来指代单独的物理应用程序,而不仅仅是逻辑分离或层.
根据我的经验,术语" 层 " 通常指的是物理应用程序分离,例如客户端层和服务器层.
MVC - 指的是3个" 层 ",关注的是围绕3个关注点,它详细说明了模型(数据),视图(UI),控制器(App Logic).
现在我已经对我的术语做出了区分..
在mvc应用程序中有单独的数据访问应用程序是否过度杀伤？
我会说No(再次取决于你的应用程序的意思),它不是矫枉过正,因为它实际上可能导致一个更易维护的系统.您的ORM 可能允许插入新的数据访问选项,但是如果您想添加新的ORM会怎样？具有明确分离的数据访问层(DAL)将在应用程序的这一方面提供更大的未来灵活性.
另一方面,根据应用程序的规模和愿景,创建一个完全独立的数据访问选项可能是过度的,但简而言之,DAL分离到不同的程序集是一个推荐的应用程序实现组合的实践MVC模式.
希望这会有所帮助,如果您需要更深入的评论.
| 归档时间： |
|
| 查看次数： |
777 次 |
| 最近记录： |