C # OOP - возвращает строку из бизнес-объекта, который выполняет проверку и вставляет запись - хорошая практика или нет? - PullRequest
0 голосов
/ 23 января 2011

Просто любопытно, может ли кто-то пролить свет на то, является ли это хорошей практикой или нет?

В настоящее время я работаю над проектом C #, который выполняет и вставляет запись и выполняет 4 или 5 методов для проверки возможности добавления записи и возвращает строку, которая сообщает уровню представления, была ли запись отправлена.или нет.

Это хорошая практика?Плюсы / минусы?

Вызов из презентации:

protected void btnProduct_Click(object sender, EventArgs e)
{

    lblProduct.Text =  ProductBLL.CreateProduct(txtProductType.Text, txtProduct.Text, Convert.ToInt32(txtID.Text);

}

Метод BLL:

public class AccountBLL
    {
        // Create The Product w/ all rules validated
        public static string CreateProduct(string productType, string product, int id)
    {

        // CHECK IF PRODUCT NAME IN DB                
        else if (ValidateIfProductNameExists(product) == true)             
    {
            return "Invalid Product Name";
        }
        // CHECK IF 50 PRODUCTS CREATED   
        else if (ValidateProductCount(id) == true)             
   {
            return "Max # of Products created Can't add Product";
        }

        // CHECK IF PRODUCT TYPE CREATED 
        else if (ValidateProductType(productType) == false)             
    {
            return "No Product Type Created";
        }

         // NOW ADD PRODUCT
         InsertProduct(productType, product,id);        


         return "Product Created Successfully";


    }

Ответы [ 5 ]

1 голос
/ 23 января 2011

Как упоминалось в предыдущем посте, используйте типы Enum. Ниже приведен пример кода, который можно использовать в вашем приложении.

public struct Result
{
    public Result(ActionType action,  Boolean success, ErrorType error) :
            this()
    {
        this.Action = action;
        this.HasSuceeded = success;
        this.Error = error;
    }

    public ActionType Action { get; private set; }
    public Boolean HasSuceeded { get; private set; }
    public ErrorType Error { get; private set; }
}

    public enum ErrorType
    {
        InvalidProductName, InvalidProductType, MaxProductLimitExceeded, None,
        InvalidCategoryName // and so on 
    }

    public enum ActionType
    {
        CreateProduct, UpdateProduct, DeleteProduct, AddCustomer // and so on
    }

    public class ProductBLL
    {
        public Result CreateProduct(String type, String name, Int32 id)
        {
            Boolean success = false;
            // try to create the product
            // and set the result appropriately
            // could create the product without errors?
            success = true;

            return new Result(ActionType.CreateProduct, success, ErrorType.None);
        }
    }
1 голос
/ 23 января 2011

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

Проверки должны быть выполнены, единственное, что вы можете улучшить, это поместить весь процесс проверки в один метод.

После вызова метода вы можете иметь одно предложение if в главномметод проверки возвращенного перечисления.

if (IsValidated(productType, product,id) == MyEnumType.Success) { }
0 голосов
/ 23 января 2011

Не рекомендуется возвращать строку со статусом метода.

Основная причина заключается в том, что это нарушает разделение проблем между уровнем пользовательского интерфейса и бизнес-уровнем. Вы нашли время, чтобы выделить бизнес-логику в ее собственный бизнес-уровень; это хорошая вещь. Но теперь бизнес-уровень в основном возвращает сообщение об ошибке непосредственно в пользовательский интерфейс. Сообщение об ошибке, отображаемое для пользователя, должно определяться уровнем пользовательского интерфейса.

С текущей реализацией бизнес-уровень также становится трудным в использовании (для тех, кто не знает о реализации явно), потому что нет контракта. Текущий контракт заключается в том, что метод вернет строку, которую вы должны отобразить пользователю. Такой подход затрудняет повторное использование. Два распространенных сценария, которые могут вызвать головную боль, это если вы хотите поддерживать новый язык (локализация) или если вы хотите представить некоторые из этих бизнес-методов в качестве службы.

Меня укусили, когда я пытался использовать какой-то старый код, подобный этому. Сценарий состоит в том, что я хочу повторно использовать метод, потому что он делает именно то, что я хочу, но я хочу предпринять некоторые действия, если происходит конкретная ошибка. В этом случае вы либо переписываете бизнес-логику (что иногда невозможно), либо вам приходится жестко кодировать ужасный оператор if в ваше приложение. например,

if (ProductBLL.CreateProduct(productType, product, ID) == 
    "Max # of Products created Can't add Product")
{
...
}

Затем приходит требование, чтобы сообщение было изменено на что-то другое («Превышено максимальное количество продуктов. Пожалуйста, добавьте меньше продуктов и повторите попытку».). Это сломает приведенный выше код. В производстве. В субботу вечером.

Итак, в итоге: не делайте этого .

0 голосов
/ 23 января 2011

Я бы порекомендовал взглянуть на платформу Validation, которую использовал Imar Spaanjaar в своей серии N-Layer Architecture . Фреймворк, который он использует, очень универсален, и он даже поддерживает локализацию с помощью файлов ресурсов для строк проверки.

0 голосов
/ 23 января 2011

Я бы использовал исключения, а не строку или перечисление ...

...