Помощь в понимании веб-сервисов и REST

Question

Помощь в понимании веб-сервисов и REST

Я очень хотел задать этот вопрос, но нашел время только сейчас.

В любом случае, было много дискуссий о веб-сервисах (да, о тех традиционных сервисах ответа SOAP-XML) и сервисах RESTful (которые сейчас нужны многим разработчикам).

Я чувствую, что хотя я понимаю концепции REST в целом, мне нужно больше учиться. Я думаю, что лучший способ полностью охватить это - показать, что это действительно лучше (акцент на **, так как лучше это субъективное слово), чем то, что делалось в настоящее время.

Рассмотрим следующие простые традиционные коды: (Этот код скопирован из корпоративного приложения с Oracle в качестве бэкэнда. Я думаю, что база данных не будет иметь большого значения, поскольку вы можете легко переключаться между SQL Server, Oracle или любой другой БД в этом отношении).

myWebService.asmx.cs

namespace MyApplication
{
    public class myWebService : System.Web.Services.WebService
    {
        private classEmployee _emp = new classEmployee();

        [WebMethod]
        public string GetEmployees()
        {
            string EmployeeData = string.Empty;
            EmployeeData = _emp.GetEmployees();
            return EmployeeData;
        }
    }
}

classEmployee.cs

using System;
using System.Collections.Generic;
using System.Data;
using System.Globalization;
using System.Data.OracleClient;

namespace MyApplication.App_Code
{
    public class classEmployee
    {
        private DataAccess _da;

        public string GetEmployees()
        {
            string employeeData = string.Empty;
            string cmd = string.Empty;
            OracleCommand oraCmd = new OracleCommand();
            DataSet ds = new DataSet();

            try
            {
                 cmd = "SELECT * FROM Employees";

                oraCmd.CommandType = CommandType.Text;
                oraCmd.CommandText = cmd;
                ds = (DataSet)_da.ExecSQLQueryCmd(oraCmd, DataAccess.ResultType.DataSet);
                employeeData = ds.GetXml
                ds.Dispose();
            }
            catch (Exception ex)
            {
                employeeData = "Error: " + "Getting Employees [GetEmployees]" + Environment.NewLine + "Details: " + Environment.NewLine + ex.Message;
            }

            return employeeData;
        }
    }
}

DataAccess.cs

using System;
using System.Collections;
using System.Configuration;
using System.Data;
using System.Data.OracleClient;

namespace MyApplication.App_Code
{
    public class DataAccess
    {
        private OracleConnection oraConn;
        private String connString;

        public enum ResultType
        {
            DataReader = 0,
            DataSet = 1,
            DataTable = 2
        }

        public DataAccess()
        {
            connString = System.Configuration.ConfigurationManager.ConnectionStrings["AppConnectionString"].ConnectionString;
        }

        public object ExecuteSQLCommand(OracleCommand oraCommand, ResultType ReturnType, string TableName = "")
        {
            OracleDataAdapter oraDataAdapter = new OracleDataAdapter(oraCommand);
            oraConn = new OracleConnection(sConnectionString);

            try
            {
                oraConn.Open();
                oraCmd.Connection = oraConn;
                oraCmd.CommandType = CommandType.Text;

                switch (ReturnType)
                {
                    case ResultType.DataReader:
                        OracleDataReader oraDataReader = null;
                        oraDataReader = oraCmd.ExecuteReader();
                        return oraDataReader;

                    case ResultType.DataSet:
                        DataSet ds = new DataSet();
                        oDataAdapter.Fill(ds);
                        oraConn.Close();
                        oraConn.Dispose();
                        return ds;

                    case ResultType.DataTable:
                        DataTable dt = new DataTable();

                        if (!string.IsNullOrEmpty(TableName))
                            dt.TableName = TableName;
                        oDataAdapter.Fill(dt);
                        oraConn.Close();
                        oraConn.Dispose();
                        return dt;
                }
            }
            catch (OracleException oException)
            {
                throw oException;
            }
            finally
            {
                oDataAdapter.Dispose();
                oDataAdapter = null;
                oraCmd.Dispose();
            }

            return null;
        }

        public int ExecuteSQLNonQueryCommand(OracleCommand oraCommand)
        {
            // This will execute any NON-QUERY command.
            //Trimmed for Brevity purposes..
        }
    }
}

Приведенный выше код говорит сам за себя. Запустите веб-сервис и получите полученные данные в формате XML. Чтобы выполнить команды без запроса, просто замените командную строку, переданную в объекте команды, и вызовите необходимый метод в классе DataAccess.cs.

Я уже поражен различными мнениями о том, почему, по крайней мере, следует избегать вышеизложенного и вместо этого пойти на вызовы типа обслуживания RESTful. Но я не видел ничего, что, по крайней мере, помогло бы преобразовать этот код, чтобы хоть как-то охватить архитектуру RESTful.

Я вполне уверен, что многие люди используют это (заметьте, я до сих пор использую много этого в настоящее время) по той причине, что:

Оно работает.
Легко внедрить, поддерживать и управлять.
Люди, которые занимаются разработкой на основе баз данных, настолько увлечены командами SQL, что возможность легко использовать те отбросы SQL, которые мы легко используем в редакторе SQL, для приложения - большой вздох облегчения. Зачем вам использовать ORM, если вы можете просто реализовать все несколько запросов (включая хранимые процедуры), используя приведенный выше пример.
Большинство примеров кода, доступных для приложений, связанных с данными, показывают тот же шаблон, что и выше (набор данных заполняется из объекта Command и возвращается как DataSet или XML и т. Д.).

Чтобы принять то, что люди называют "Лучшей практикой" в этой области кодирования, нужно показать, почему это лучше, и как гораздо проще сделать такую вещь по сравнению с той, которая была опробована и протестирована для работы.

Если бы я мог попросить наших коллег-опытных разработчиков показать мне, как преобразовать его, и дать некоторые объяснения, почему преобразование в REST было бы лучше (через код), то я был бы более чем благодарен за это.

Цените ваш вклад. Благодарю.

Дополнительно: я просто хочу отметить, что, хотя это правильно, у меня появились некоторые сомнения в том, что этот подход является лучшим после прочтения этой статьи:

http://www.codeproject.com/Feature/WeirdAndWonderful.aspx?msg=4324770

В статье выше, как прокомментировал один из них, говорилось: "Нашел это в веб-сервисе, который я обновляю. Трудно найти что-нибудь, что не так с этим".

Я пытаюсь также установить, что ДЕЙСТВИТЕЛЬНО не так с этим, поскольку я нахожусь в безвыходном положении.

Позвольте мне привести несколько ситуаций:

Клиент / клиент просит вас предоставить приложение, которое запрашивает информацию, хранящуюся в базе данных.
Вы придумали решение, используя вышеуказанный метод. Требования, задаваемые заказчиком, предоставляются. Решение надежное, быстрое и ремонтопригодное.

Итак, по сути, другой вопрос, который я долго задаю, - ЧТО на самом деле не так с кодом выше?

4

sql .net rest web-services data-access

Источник

user159342 03 авг '12 в 16:47

1 ответ

Решение

Другие вопросы по тегам sql .net rest web-services data-access

user1195080 03 авг '12 в 17:06 2012-08-03 17:06 · Accepted Answer · 2012-08-03 17:06

Чтобы преобразовать это, хотя это не в моей голове, это будет выглядеть примерно так.

namespace MyApplication 
{ 
    public class myWebService : System.Web.Services.WebService 
    { 
        private classEmployee _emp = new classEmployee(); 

        [HttpGet]
        public string GetEmployees() 
        { 
            string EmployeeData = string.Empty; 
            EmployeeData = _emp.GetEmployees(); 
            return EmployeeData; 
        } 
    } 
}

И вы можете вернуть эту строку во все, что легко конвертируется потребителем. Если это JavaScript, то я бы порекомендовал JSON, поскольку он нативный.

Давайте поговорим о ReST на минуту. Часть, которую я нахожу наиболее забавной ReST это старомодно ASMX услуги были ReSTful. Но, поскольку у ИТ-индустрии есть проблема с принятием того факта, что старые технологии, возможно, были более правильными с самого начала, им пришлось назвать это чем-то новым и новым.

Они сделали это с термином Client/Server также. IBM выполняла операции клиент-сервер за годы до того, как Microsoft пришла и сказала: "Эй, нам нужно перенести все на ПК. Что ж, когда это начало становиться все менее популярным, потому что развертывание было кошмаром, они поняли, о боже, нам нужно вернуться к тому, что IBM делала все это время. Большие серверы, тупые клиенты и простые развертывания. Но они не могли назвать это так, потому что индустрия не приняла бы это, и Microsoft не хотела этого, поэтому они назвали это The Cloud (вставьте бум, бум, бум музыку здесь).

Итак, перенесемся в SOAP. Люди хотели иметь возможность передавать сложные объекты по проводам и не должны десериализовать их, и они хотели гибкости протокола. Итак, SOAP дал вам обоим, Microsoft генерирует представление клиента и десериализацию, а уровень WCF обеспечивает реальную гибкость протокола, тогда как ReST может передаваться только по HTTP, потому что он использует стандартные глаголы.

Итак, настоящий ответ на ваш вопрос: что вам нужно?

SOAP более тяжелый и часто менее производительный на очень больших наборах данных, чем ReST, потому что это не нативная операция для браузера, а конверт большой. Но опять же, сколько данных вы действительно должны передавать клиенту?!?
Хотите ли вы генерацию одним кликом модели на стороне клиента? Тогда используйте SOAP.
Хотите ли вы сделать API более доступным для других парадигм программирования? Тогда используйте ReST.
Вы хотите пойти по пути остальной части отрасли в данный момент? Тогда используйте ReST.

Предстоит еще намного больше обсуждений, но это должно помочь вам начать. ReST не лучше, чем SOAP, он другой и решает другой набор проблем. Не позволяйте себе или другим говорить с вами о законе инструмента.