【问题标题】:Call Business Layer method调用业务层方法
【发布时间】:2014-03-05 06:36:07
【问题描述】:

我对多层架构和 asp.net mvc 还是很陌生。 我想知道哪个是调用业务层方法的好习惯。

1) 从控制器调用业务层方法,填充视图模型并将视图模型传递给视图。

2) 直接从视图调用业务层方法。

请告诉我这两种方法的优缺点。 如果解释“在哪种情况下使用这两种方法”将不胜感激

【问题讨论】:

    标签: c# asp.net asp.net-mvc design-patterns


    【解决方案1】:

    这几乎是一个征求意见的问题,但我认为值得解释一下,尽管你可以通过足够的研究找到这一点。

    选项 1 是可行的方法,可能 +80% 同意。

    你会遇到“取决于”的答案。这取决于你需要打破多少东西。从学术上讲,您应该松散地与高内聚力耦合。一切都很好,但在现实世界中很少有绝对的,因为完美的架构更多的是“及时”设计而不是学术问题,否则你永远不会把东西投入生产。因此,作为开发人员,您必须对妥协的地方做出判断(而且您会妥协)。

    所以这里是基于意见的地方:

    a) 高内聚的松散耦合意味着更好的可测试性/可维护性/可扩展性,但代价是更大的抽象,即更多的开发时间。

    b) 反过来意味着更少的商品,但也意味着更少的前期开发时间,也就是“把它拿出来,不要再告诉我(你的老板)关于好的架构该死的事!”

    优秀的开发人员总是为 a) 努力。问题是我们大多数人都必须在取得进步之间取得平衡,所以我们倾向于滑向 b)(不情愿地)

    所以为了进一步讨论(如果您还在阅读)...a) 的示例,还有很多其他正确的 a,这只是一种风格:

    假设您的视图模型包含渲染 UI 所需的所有内容,视图所需的最少数据 + 直接从 UI 调用的函数。它不应该代表与领域模型有关的业务逻辑。领域模型应该代表代表它们所包含的领域所必需的数据。业务逻辑层,这里指的是服务层,应该是对领域进行操作的功能。

    泽例:

    假设我们有一个拥有多个帐户的用户。会有一个用户类和帐户类。这些组合在 UserAccounts 类中(User 属性和 Accounts 属性(数组)。

    根据您决定域的方式,有 UserService 类或 UserService + AccountService + UserAccountService 类组合。

    然后假设您有用户(UserView 类)和用户详细信息(UserDetailView 类)视图。 UserView 是 User 类 + 帐户的聚合表示(但不是所有详细信息)+ UI 直接调用函数。 UserDetailView代表的是用户+各个账号的详细信息+UI直接调用函数。

    User 控制器有两个函数(当然还有很多,但只是这些用于解释),getUsers 和 getUserDetail。

    • GetUsers 调用返回 UserAccounts 对象数组的用户服务 然后通过模型构建器传递,该模型构建器返回 UserView 数组 然后控制器传递给“摘要”视图的对象。
    • GetUserDetail 调用返回 UserAccounts 的用户服务 然后通过返回一个模型构建器的对象 然后控制器将其传递给 UserDetailView 对象 “详细”视图。

    【讨论】:

    • 这做了必要的解释。
    • 我宁愿选择合适的工具来完成这项工作,也不愿选择好工具然后一锤定音。
    • 我喜欢@Shank 提出问题的方式,每个问题都有优点和缺点。我不确定你是这样回答的(至少不是很清楚)。你能编辑总结一下吗?
    【解决方案2】:

    使用 MVC,您的处理(如调用和填充模型)将属于模型本身。控制器需要尽可能“愚蠢”,基本上只是说“好的,我需要这个模型并将它发送到那个视图”

    这是我的一个模型的 VB.NET 版本(我使用 StackOverflow 的 Dapper ORM 的自定义版本作为我的数据库层。顺便说一句,这是一个未完成的模型,用户信息的数量不包含在其中然而):

    Public Class UserAccount    
        Public Property Employee_ID() As Integer
        Public Property Email_Address() As String
        Public Property Location_ID() As String
        Public Property Department_ID() As String
        Public Property Company_ID() As String
        Public Property Password_Expiry() As DateTime
        Public Property Win_User_Name() As String
        Public Property First_Name() As String
        Public Property Last_Name() As String
        Public Property Message_Number() As Integer
        Public Property Message_Text() As String
        Public Property Password() As String
    
        Public Overrides Function ToString() As String
            Dim serializer As JavaScriptSerializer = New JavaScriptSerializer
            Dim result As String = serializer.Serialize(Me)
            Return result
        End Function
    
        Public Function FromString(str As String) As UserAccount
            Dim serializer As JavaScriptSerializer = New JavaScriptSerializer
            Return serializer.Deserialize(Of UserAccount)(str)
        End Function
    
        Public Function GetUserInfo() As UserAccount 'Returns user info as a strongly typed object from what is saved in the cookie
            Dim user As UserAccount
            Dim cookie As HttpCookie = DirectCast(System.Web.HttpContext.Current.Request.Cookies(FormsAuthentication.FormsCookieName), HttpCookie)
            Dim ticket As FormsAuthenticationTicket = FormsAuthentication.Decrypt(cookie.Value)
    
            user = Me.FromString(ticket.UserData)
    
            Return user
        End Function
    
        Public Shared Function Encrypt(password As String, Win_User_Name As String)
    
            Dim _password As New StringBuilder
            Try
    
               'encryption stuff happens here
            Catch er As Exception
                Return ""
            End Try
    
            Return _password.ToString
    
        End Function
    
    End Class
    

    现在控制器需要做的就是实例化这个模型并将数据提供给视图

    【讨论】:

    • 使用这种模式有什么优点,使用其他模式有什么缺点。你能提供任何链接吗
    • google 将成为你的朋友,然而,MVC 模式比其他任何模式的优势在于你的逻辑分离。这与您(可能)在过去十年的 .NET 和 OOP 中一直使用的业务/数据层类型的想法没有太大区别。它更加结构化,并为任何了解该模式的人提供了一种快速进入并做事的方法。由于我们的团队采用 MVC 作为我们项目的模式,因此接管其他开发人员的工作或让其他人修改我自己的工作变得轻而易举,而无需依赖更改的沟通
    猜你喜欢
    • 2016-01-11
    • 2018-05-21
    • 1970-01-01
    • 2011-08-02
    • 2011-07-10
    • 1970-01-01
    • 1970-01-01
    • 2015-07-09
    • 2014-09-13
    相关资源
    最近更新 更多