Должен ли я вызывать методы BLL непосредственно в моем контроллере Asp.Net MVC 3? - PullRequest
Новая
       28

Должен ли я вызывать методы BLL непосредственно в моем контроллере Asp.Net MVC 3?

0 голосов
/ 14 сентября 2011

У меня есть уровень бизнес-объектов, который я использую в нескольких других приложениях, и я хочу использовать его в своем приложении MVC. Меня больше беспокоит проблема дизайна: правильно ли иметь что-то вроде следующего: 

using Interface.MyOtherProject
public class MyMVCController: Controller
{
    [HttpGet]
    public string GetSomethingById(Int32 id)
    {
        return new JavaScriptSerializer().Serialize(MyObject.GetById(id));
    }

}

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

Спасибо за помощь!

Hanlet

Ответы [ 2 ]

2 голосов
/ 14 сентября 2011

Когда нам пришлось принять это решение, мы пошли на создание моделей представления, которые инкапсулировали / отражали наши бизнес-объекты. Это дает нам больше контроля над тем, как должны выглядеть объекты при сериализации в json без необходимости добавлять логику представления в наш бизнес-уровень.

Пример. Предположим, у нас есть бизнес-объект Person: 

public class Person
{
  public int Id {get;set;}
  public string Name {get;set;}
}

Когда клиент собирается использовать наш веб-сервис, мы бы не хотели, чтобы он знал, что такое значение Id, поскольку это внутренний ключ базы данных. Два варианта, которые мы рассмотрели для исправления, а именно: 1) добавьте атрибут [ScriptIgnore] к свойству Person.Id или создайте отдельную модель представления для нашей персоны, которая специально адаптирована для домена представления.

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

Это очень упрощенный сценарий, но более масштабная идея все еще остается неизменной. Благодаря отдельным моделям представлений вы можете включать / исключать данные в своем представлении, не нарушая чистоту вашего бизнес-уровня.

1 голос
/ 14 сентября 2011

Я не вижу здесь никаких явных проблем с дизайном.Чтобы обратиться к одному конкретному пункту в вопросе:

я должен вместо этого сделать это в модели и вернуть эту строку непосредственно из модели

Вы имеете в виду, если модель предоставляетJSON-сериализованная строка?Я бы сказал нет.Модель является просто представлением бизнес-концепции и содержит логику, которая действует на эту концепцию.JavaScriptSerializer в основном создает представление об этой модели.Это логика пользовательского интерфейса и принадлежит именно там, где она есть, в коде представления.Модель не должна заботиться о том, как ее рассматривают, она просто беспокоится о состоянии того, что она представляет.

если я переписываю свой BLL в мою модель

I 'Я не уверен, что вы спрашиваете здесь.Модели должны содержать бизнес-логику, это точно.Если ваш BLL - это просто набор утилитарных методов, которые используют модели в качестве чистых DTO, то вы, возможно, захотите перейти к переносу этой бизнес-логики в сами модели.Но трудно сказать с помощью представленного здесь кода.

Когда я вижу MyObject.GetById(id), я представляю, что GetById - это просто статический фабричный метод в модели MyObject, который вызывает любые необходимые зависимости, такие какхранилище DAL (может быть предоставлено не только параметрами метода, но иными способами, но, надеюсь, не внутренне созданным), и возвращает экземпляр MyObject, что выглядит нормально.Я сам часто использую этот же шаблон, иногда экспериментируя с тем, как я называю методы, чтобы сделать все это более плавным.

...