Шаблон службы репозитория WCF с каркасом сущностей

Question

Мне нужен слой представления в silverlight, asp.net и т. Д., Так что все через сервисы wcf. У меня есть ряд сомнений в моей реализации уровня репозитория, уровня сервиса, сервисов wcf

вещи, которые я сейчас делаю

1. У меня есть репозиторий, его не для каждой таблицы, он создан для совокупного корня
2. У меня есть сервисный слой для выполнения группы действий с участием нескольких хранилищ
3. Служба WCF переносит методы на уровень службы и уровень хранилища.
4. Объекты автоматически генерируются EF
5. Объекты передаются и возвращаются на сервисный уровень в виде полного графика.

6. У меня есть два конкретных класса со всем хранилищем, и служба называется repositorycontainer и контейнером службы, контейнер хранилища передается службе.

Моя база репозитория

public class RepositoryBase
    {
        public DataBaseContext _Context;
        public RepositoryContainer _RepositoryContainer;
        public RepositoryBase(RepositoryContainer repositoryContainer)
        {
            _RepositoryContainer = repositoryContainer;
            _Context = repositoryContainer.Context;
        }
        public RepositoryBase()
        {
            _RepositoryContainer = new RepositoryContainer();
            _Context = _RepositoryContainer.Context;
        }


    }

Мой репозиторий контейнер

public class RepositoryContainer
    {
        public RepositoryContainer()
        {
            Context = new DataBaseContext();
        }
        public RepositoryContainer(DataBaseContext context)
        {
            Context = context;
        }
 public DataBaseContext Context
    {
        get;
        set;
    }


        public SurveyRepository _SurveyRepository;
        public SurveyRepository SurveyRepository
        {
            get
            {
                return _SurveyRepository ?? (_SurveyRepository = new SurveyRepository(this));
            }           
        }


}

Мой сервисный контейнер

 public class ServiceContainer
    {
        public ServiceContainer()
        {
            RepositoryContainer = new RepositoryContainer();
        }
        public ServiceContainer(RepositoryContainer container)
        {
            RepositoryContainer = container;
        }


        public RepositoryContainer RepositoryContainer
        {
            get;
            set;
        }
   public SurveyService _SurveyService;
        public SurveyService SurveyService 
        {
            get
            {
                return _SurveyService?? (_SurveyService= new SurveyService(this));
            }           
        }


    }

Для выполнения операции я просто создаю RepositoryContainer или ServiceContainer.

затем звонит

RepositoryContainer.Repository.Method()
ServiceContainer.Service.Method()

Мои сомнения

1. Это сервисный / репозиторий контейнер?

2. У меня уже есть сервисный уровень, так как у меня есть сервис wcf, который я называю текущим сервисным сервис-слоем или что-то в этом роде?

3. Мне нужно самому вызывать методы репозитория, например: GetCategory() и т. Д., А также все методы на уровне сервиса, поэтому мне нужно обернуть и методы, и сервис в сервис wcf, это нормально?

4. Где делать кеширование? так как я использую EF, я думаю, что есть какой-то способ использовать провайдер кеша с EF,

Answer 1

Это сервисный / репозиторий контейнер?

RepositoryContainer класс содержит "SurveyRepository" - но не должен ли SurveyRepository быть экземпляром RepositoryContainer? То же самое для ServiceContainer и "SurveyService". Для меня было бы больше смысла, если бы они были (хотя трудно комментировать точно, не будучи более знакомым с проектом).

Вы бы тогда имели: ServiceContainer SurveyService = new ServiceContainer(..);

Как вы понимаете, у меня сложилось впечатление, что "SurveyService" - это конкретная бизнес-концепция, но она заключена в более общий тип (ServiceContainer); то же самое для SurveyRepository / RepositoryContainer.

Это нарушит SRP, принцип общего закрытия и, возможно, принцип общего повторного использования.

Я не уверен, что думают другие, но я также не фанат именования экземпляров после их типов (кроме самых простых из senarios - что это не так): public SurveyRepository SurveyRepository Имя типа должно отражать то, что тип (или делает), который будет заключен в кавычки, отличается от конкретного его экземпляра (например, ServerContainer и ServeyService).

У меня уже есть сервисный уровень, так как у меня есть сервис wcf, который я называю текущим сервисным сервис-слоем или что-то в этом роде?

а также

Поэтому мне нужно изменить имя моего сервисного (BL) уровня на что-то сервисное обертка или что-то подобное, затем на сервисном уровне wcf я определяю методы в репозитории и сервисе, затем просто вызываю соответствующие методы в сервисе, репозитории

Как правило, любой повторно используемый BL должен быть в отдельном пакете и не заключаться (например, "жестко закодировано") в сервисный уровень или сервис WCF и т. Д. Затем вы создадите конечные точки службы, которые располагаются поверх BL. Если у вас есть бизнес-транзакции, которые охватывают разные бизнес-объекты в разных пакетах, то вам нужно поместить этот более высокий уровень оркестровки куда-нибудь выше - я думаю, это может пойти на уровне сервиса, но это не тривиальная вещь, вы ' Вам нужно будет тщательно продумать, где лежат определенные обязанности.

Если транзакция обрабатывает различные бизнес-объекты в одном и том же пакете, то оркестровка намного проще и может быть выполнена с другим типом BL, предназначенным для обработки этого задания, которое будет частью этого пакета, а не на уровне обслуживания.

Что касается именования - перейдите к доске и наметьте все, а затем переименуйте все, как требуется. По крайней мере, с помощью одного связного обзора вы сможете понять все.

Пакеты BL должны быть названы в соответствии с тем, что они делают - в деловом плане. Службы WCF, которые обертывают их, должны иметь подходящее имя, которое может включать ссылку на тип используемого канала (JSON, WebService и т. Д.). Поскольку вы можете изменить канал, который служба WCF использует с помощью config (если служба спроектирована правильно), это может быть не очень хорошей идеей - но если предположить, что это не так, то дополнительная ясность может оказаться полезной.

Эти статьи могут быть полезны:

• http://blogs.oracle.com/christomkins/2009/07/my_thoughts_on_service_naming.html
• http://ea.typepad.com/enterprise_abstraction/2006/08/service_naming_.html
• Какое соглашение об именах вы используете для сервисного уровня в приложении Spring MVC?

Мне нужно самому вызывать методы репозитория, например: GetCategory() и т. Д., А также все методы на уровне сервиса, поэтому мне нужно обернуть и методы, и сервис в сервис wcf, это нормально?

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

Где делать кеширование? поскольку я использую EF, я думаю, что есть какой-то способ использовать провайдер кеша с EF

Я не знаю, сможете ли вы кешировать в EF4, но меня это не удивит, если вы сможете. Где делать кеширование? - Это зависит от того, где бутылку стукнут, что вы пытаетесь устранить.

В вашем RepositoryContainer поле _SurveyRepository является открытым - не должно ли оно быть приватным? Иначе, почему есть свойство только для чтения (get) SurveyService?

public SurveyRepository _SurveyRepository;