Не вдаваясь в подробности, я пытаюсь разработать сервисное решение, которое будет использоваться несколькими клиентскими приложениями.Решение позволяет администраторам создавать и изменять шаблоны документов, которые используются обычными пользователями для ввода данных.Я намерен сделать приложение инструментом обучения для лучших практик, техник и т. Д.
И в то же время я должен приспособиться к шизофренической среде, потому что «силы, которые могут быть» никогда не могут держатьсяих решения относительно технологий и инструментов.Например, сегодня я использую Linq-to-SQL, потому что они не готовы перейти на EF4, но есть также обсуждение перехода на NHibernate.Поэтому я должен сделать код как можно более невежественным, чтобы свести к минимуму требуемую работу, если мы изменим инструменты OR / M.
На этом этапе я также ограничен использованием метода частичных классов для расширения Linq.классы -to-SQL, поэтому они реализуют интерфейсы, определенные на моем бизнес-уровне.Я не могу использовать POCO, потому что руководство настаивает на том, чтобы мы использовали все встроенные инструменты и т. Д., Поэтому я должен поддерживать конструктор Linq-to-SQL.
Тем не менее, мой сервисный интерфейс имеет метод StartSession, который принимаетидентификатор шаблона в его подписи.Операция выполняется следующим образом:
- Если в базе данных уже существует сеанс для текущего пользователя и указанного шаблона, обновите запись, чтобы показать текущую активность.Если нет, создайте новый объект сеанса.
- Сеанс связан с экземпляром шаблона, назовите его «форма».Поэтому, если сеанс новый, мне нужно получить информацию о шаблоне, чтобы создать новую «форму», связать ее с сеансом, а затем сохранить сеанс в базе данных.С другой стороны, если сеанс уже существовал, тогда мне нужно также загрузить «форму» с данными, введенными пользователем и сохраненными в сеансе ранее.
- Наконец, сеанс (с определением формы и данными) возвращается вызывающей стороне.
Моя первая задача - создать четкое разделение между логическими уровнями моего приложения.Второе - поддерживать постоянное невежество (как упомянуто выше).В-третьих, я должен быть в состоянии проверить все, поэтому все зависимости должны быть выведены наружу для легкой насмешки.Я использую Unity в качестве инструмента IoC, чтобы помочь в этой области.
Для этого я определил класс обслуживания и контракты данных, необходимые для поддержки интерфейса службы.Класс обслуживания будет иметь зависимость, внедренную из бизнес-уровня, который фактически выполняет работу.И вот тут мне стало грязно.
Я пытался пойти по пути «Единица труда и хранилище», чтобы помочь с невежеством упорства.У меня есть ITemplateRepository и ISessionRepository, к которым я могу получить доступ из моей реализации IUnitOfWork.Класс обслуживания получает экземпляр моего класса SessionManager (в моем BLL).SessionManager получает реализацию IUnitOfWork через внедрение конструктора и делегирует все постоянство UoW, но я обнаруживаю, что играю в игру оболочки с различной логикой.
Должна ли вся описанная выше логика быть в классе SessionManager или, возможно,реализация UoW?Мне нужно как можно меньше логики в реализациях репозитория, потому что изменение платформы доступа к данным может привести к нежелательным изменениям логики приложения.Поскольку мой репозиторий работает с интерфейсом, как мне лучше всего создать новый сеанс (имея в виду, что действительный сеанс имеет ссылку на шаблон, то есть на используемую форму)?Было бы лучше по-прежнему использовать POCO, даже если мне нужно поддерживать конструктор и использовать такой инструмент, как AutoMapper внутри реализации репозитория, для обработки перевода объектов?
Тьфу!
Я знаю, что просто застрял в параличе анализа, поэтому, вероятно, все, что мне нужно, - это немного подтолкнуть.Что было бы идеально, если бы кто-то мог привести пример того, как бы вы решили проблему, учитывая определенные мной бизнес-правила и архитектурные ограничения.