Как спроектировать это многоуровневое решение ASP.NET? - PullRequest
5 голосов
/ 08 апреля 2009

У меня проблема с попыткой макета моего решения VS, и я хотел бы получить несколько предложений, пожалуйста.

В настоящее время макет моего решения выглядит следующим образом: -

Foo.Models
Foo.Repositories
Foo.Services
Foo.Web (an ASP.NET MVC application)

мой сайт (Foo.Web) вызывает различные методы в пространстве имен Foo.Services. Идея в том, что Services обрабатывает всю бизнес-логику . Пространство имен Model - это просто POCO объекты. Repositories Пространство имен не требует пояснений.

Внедрение зависимостей от конструкторов с интерфейсами обрабатывает черную магию того, какой слой требует какого компонента.

Проблема: я хочу добавить Windows Код Workflow Foundation (WWF) в решение, но поместите этот код WWF в тот же Foo.Services.dll.

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

Я надеялся, что веб-сайт только когда-либо вызывает пространство имен Services, чтобы что-то делать.

В конце концов, сервис является основным интерфейсом между пользовательским интерфейсом и бизнес-логикой IMO. Тот факт, что я технически использую WWF, не должен беспокоить кого-то, кто занимается кодированием в интерфейсе IUI.

Поскольку dll рабочего процесса вызывает методы в dll служб, dll службы не может вызывать методы в рабочем потоке из-за циклической зависимости .

Я также не могу переместить весь код рабочего процесса в DLL-библиотеку Services, потому что DLL-библиотека Services должна иметь какой-то особый тип проекта (типа Windows Workflow).

Итак ... я не уверен, что делать?

Как я могу сделать так, чтобы потребители ссылались только на пространство имен Служб для бизнес-материалов, а тот факт, что я использую этот бизнес-контент в WWF, скрыт от потребителя?

Нужно ли мне сделать проект WWF и переместить в него весь код моих сервисов, отбросить старый сервисный проект? Это не звучит очень многократно. Что произойдет, если я решу не использовать WWF для обработки определенных действий в трубопроводе и использовать что-то еще?

Вот некоторый код, чтобы помочь объяснить.

HomeController.cs
public ActionResult Index()
{
   // StockService was created using constructor dependency injection.
   var viewData = _stockService.GetStocks(StockType.MostPopular);
   return (viewData)
}

StockService.cs
public class StockService : IStockService
{
    public IEnumerable<Stock> GetStocks(StockType stockType)
    {
        // Dependency Injection defines if the Pipeline is WWF
        // or something else (eg. plain ole functions).
        var stocks = _stockPipeline.GetStocks(stockType);

        // Cache result.

        // Update repostiory. (example of calling the repository)
        _sqlRepostiory.SaveSomeRandomData("Jon Skeet Was Here.");

        return stocks. // Returns a POCO.
    }
}

Спасибо, выглядывает.

Ответы [ 3 ]

1 голос
/ 08 апреля 2009

Вы смотрели проект MVC Store от Rob Connery / Kona ? Он делает очень похожую вещь с WF , и его проект выложен несколько похожим образом . Это может быть хорошее руководство для того, что вы делаете. Я знаю, что он работал с каким-то экспертом Workflow Foundation по разработке своей интеграции.

0 голосов
/ 08 апреля 2009

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

0 голосов
/ 08 апреля 2009

Возможное решение - добавить слой «Application»

Application ---> Services
                    ^
                    |
            \--> Workflow

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

...