本文是小编为大家收集整理的关于服务层的目的和ASP.NET MVC 2的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
为了了解MVC 2并试图使我的公司采用它作为未来开发的可行平台，我最近一直在做很多阅读.在过去的几年中，与ASP.NET合作了，我有一些赶上.
目前，我了解存储库模式，模型，控制器，数据注释等.但是有一件事使我无法完全理解以开始参考应用程序的工作.
第一个是服务层模式.我在堆栈溢出上阅读了许多博客文章和问题，但我仍然不完全理解这种模式的目的.我在MvCcentral上观看了Golf Tracker应用程序的整个视频系列，还查看了他发布的演示代码，在我看来，服务层只是围绕存储库模式的另一个包装器，根本无法执行任何工作.<<<<<<<<<<
我还阅读了这篇文章: http://www.asp. net/learn/mvc/tutorial-38-cs.aspx 似乎有点回答我的问题，但是，如果您使用数据注释执行验证，这似乎是不必要的.
我一直在寻找演示，帖子等.但是我似乎找不到任何简单地解释模式并给我引人入胜的证据来使用它的东西.
有人可以为我提供二年级(好的，也许是五年级)使用这种模式，如果不这样做，我会损失什么，如果我这样做，我会收获什么?
推荐答案
在MVC模式中，您的责任在3个玩家之间分开:模型，视图和控制器.
该模型负责制作业务工作，视图呈现业务结果(也向用户提供输入)，而控制器的作用就像模型和视图之间的胶水一样，将内部运作分开彼此的彼此.
该模型通常由数据库备份，因此您有一些Daos访问该模型.您的业务做一些...好吧...业务和存储或从数据库中检索数据.
但是谁协调道斯?控制器?不！该模型应该.
输入服务层.该服务层将为控制器提供高级服务，并将在幕后管理其他(DAOS，其他服务等).它包含您的应用程序的业务逻辑.
如果您不使用它会发生什么?
您必须将业务逻辑放置在某个地方，而受害者通常是控制器.
如果控制器以Web为中心，则必须接收其输入并作为HTTP请求，响应提供响应.但是，如果我想从Windows应用程序中调用我的应用程序(并获取与RPC或其他内容通信的Windows应用程序访问)怎么办?然后怎样呢?
好吧，您必须重写控制器并使逻辑客户端不可知.但是有了服务层，您已经拥有了.是的，您不需要重写.
服务层提供与与特定控制器实现无关的DTO的通信.如果控制器(无论哪种类型的控制器)提供了适当的数据(无元来源)，您的服务层将为呼叫者提供服务，并将呼叫者隐藏在涉及的业务逻辑的所有责任中.
其他推荐答案
我必须说我同意DPB的同意，即包装器，即服务层可重复使用，可模拟，我目前正在将此层包含在我的应用中...以下是一些问题/要求我正在思考(很快:p)，可能会帮助您...
1.多个门户网站(例如Bloggers Portal，客户端门户，内部门户)将需要许多不同的用户访问.它们都必须是单独的ASP.NET MVC应用程序(一个重要的要求)
2.在应用程序本身中，对数据库的一些调用将是相似的，方法和数据从存储库层处理的方式.毫无疑问，每个模块/门户的某些控制器将精确地制作或同一调用的超载版本，因此可能需要使用服务层(与接口的代码)，然后我将在单独的类项目中编译.
3.如果我为我的服务层创建一个单独的类项目，我可能需要为数据层做相同的操作或将其与服务层结合，并使模型远离Web项目本身.至少随着我的项目的发展，我可以抛出数据访问层(即linqtosql-> nhibernate)，或者团队成员可以在任何其他项目中处理任何代码而无需工作.不利的一面是他们可以炸毁一切哈哈...
问题描述
In an effort to understand MVC 2 and attempt to get my company to adopt it as a viable platform for future development, I have been doing a lot of reading lately. Having worked with ASP.NET pretty exclusively for the past few years, I had some catching up to do.
Currently, I understand the repository pattern, models, controllers, data annotations, etc. But there is one thing that is keeping me from completely understanding enough to start work on a reference application.
The first is the Service Layer Pattern. I have read many blog posts and questions here on Stack Overflow, but I still don't completely understand the purpose of this pattern. I watched the entire video series at MVCCentral on the Golf Tracker Application and also looked at the demo code he posted and it looks to me like the service layer is just another wrapper around the repository pattern that doesn't perform any work at all.
I also read this post: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx and it seemed to somewhat answer my question, however, if you are using data annotations to perform your validation, this seems unnecessary.
I have looked for demonstrations, posts, etc. but I can't seem to find anything that simply explains the pattern and gives me compelling evidence to use it.
Can someone please provide me with a 2nd grade (ok, maybe 5th grade) reason to use this pattern, what I would lose if I don't, and what I gain if I do?
推荐答案
In a MVC pattern you have responsibilities separated between the 3 players: Model, View and Controller.
The Model is responsible for doing the business stuff, the View presents the results of the business (providing also input to the business from the user) while the Controller acts like the glue between the Model and the View, separating the inner workings of each from the other.
The Model is usually backed up by a database so you have some DAOs accessing that. Your business does some...well... business and stores or retrieves data in/from the database.
But who coordinates the DAOs? The Controller? No! The Model should.
Enter the Service layer. The Service layer will provide high service to the controller and will manage other (lower level) players (DAOs, other services etc) behind the scenes. It contains the business logic of your app.
What happens if you don't use it?
You will have to put the business logic somewhere and the victim is usually the controller.
If the controller is web centric it will have to receive its input and provide response as HTTP requests, responses. But what if I want to call my app (and get access to the business it provides) from a Windows application which communicates with RPC or some other thing? What then?
Well, you will have to rewrite the controller and make the logic client agnostic. But with the Service layer you already have that. Yyou don't need to rewrite things.
The service layer provides communication with DTOs which are not tied to a specific controller implementation. If the controller (no matter what type of controller) provides the appropriate data (no mater the source) your service layer will do its thing providing a service to the caller and hiding the caller from all responsibilities of the business logic involved.
其他推荐答案
I have to say I agree with dpb with the above, the wrapper i.e. Service Layer is reusable, mockable, I am currently in the process of including this layer inside my app... here are some of the issues/ requirements I am pondering over (very quickly :p ) that could be off help to youeself...
1. Multiple portals (e.g. Bloggers portal, client portal, internal portal) which will be needed to be accessed by many different users. They all must be separate ASP.NET MVC Applications (an important requirement)
2. Within the apps themselves some calls to the database will be similar, the methods and the way the data is handled from the Repository layer. Without doubt some controllers from each module/ portal will make exactly or an overloaded version of the same call, hence a possible need for a service layer (code to interfaces) which I will then compile in a separate class project.
3.If I create a separate class project for my service layer I may need to do the same for the Data Layer or combine it with the Service Layer and keep the model away from the Web project itself. At least this way as my project grows I can throw out the data access layer (i.e. LinqToSql -> NHibernate), or a team member can without working on any code in any other project. The downside could be they could blow everything up lol...
更多相关问答
联系站长