Организация приложения по слоям

Question

Я занимаюсь разработкой части приложения с именем A. Приложение, в которое я хочу подключить свою DLL, под названием приложение B, находится в vb 6, а мой код - в vb.net. (Приложение B будет со временем преобразовано в vb.net). Мой главный вопрос: как мне лучше организовать свой код (приложение A)?

Я хочу разделить приложение A на слои (Сервис, Бизнес, Доступ к данным), поэтому будет легко интегрировать приложение A в B, когда B преобразуется в vb.net. Я также хочу узнать обо всех темах, таких как многоуровневая архитектура, шаблоны, инверсия зависимостей, структура сущностей и так далее. Хотя мое приложение (A) небольшое, я хочу организовать свой код наилучшим образом.

Приложение, с которым я работаю (A), использует веб-службы для аутентификации пользователей и для отправки схемы в организацию. Пользователь приложения B выбирает пункт меню в приложении B, а затем некоторые функции в моем приложении A называются.

В приложении A у меня есть автоматически сгенерированный класс схемы из схемы xsd. Я заполняю этот объект схемы данными и сериализую объект в строку памяти (это хорошее решение для использования строки памяти, мне пока не нужно сохранять данные), оборачиваю XML внутри блока CDATA и возвращаю блок CDATA в виде строки и назначить блок CDATA строковому свойству веб-службы.

Я также использую Entity Framework для связи с базой данных (чтобы узнать, как это сделать для будущей работы с приложением B). У меня есть две сущности в моем .edmx, Пользователь и Плательщик. Я также хочу использовать шаблон хранилища (это хороший выбор?), Чтобы сделать фасад между DAL и BLL.

В моем приложении есть функции для GeneratingSchema (заполнение объекта схемы данными), GetSchemaContent, GetSchemaInformation, GenerateCDATABlock, WriteToTextFile, MemoryStreamToString, EncryptData и некоторые функции, которые используют веб-сервисы, такие как SendShema, AuthenticateUser, GetAvalibelServServ и другие.

Я не уверен, куда мне все это положить? Я думаю, что у меня должны быть некоторые интерфейсы, такие как IRepository, ISchema (контракт для автоматически сгенерированного класса схемы, как я могу это сделать?), ICryptoManager, IFileManager и т. Д., И классы, реализующие интерфейсы.

Мой DAL будет основой Entity. И мне нужен фасад хранилища в моем BLL (IRepository, UserRepository, PayerRepository) и классы для управления (как классы, о которых я упоминал выше), содержащие функции, такие как WriteToFile, EncryptData… ..

Является ли это хорошим решением (нужен ли мне сервисный уровень, весь мой графический интерфейс которого находится в приложении B) и как я могу организовать свои слои, интерфейсы, классы и функции в Visual Studio?

Заранее спасибо.

Answer 1

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

Для вызова приложения B (VB6)приложение / сборки A, я собираюсь предположить, что вы представляете соответствующие части приложения A как компоненты COM, используя ComVisibleAttribute s и аналогичные, во многом как описано в this artcle .Я знаю только один другой способ ( WCF поверх COM ), но я никогда не пробовал сам.

Разделение ваших решений на различные уровни и уровни является очень субъективным / спорнымтема и всегда сводится к сочетанию личных предпочтений, бизнес-требований, наличия времени и т. д. Однако, независимо от глубины ваших уровней и уровней, полезно понимать, как и почему.

Для начала вот пара статей:

• Общий обзор Википедии "Многоуровневая архитектура"
• Собственный MSDN "Создание N-Уровневое приложение в .Net "

Inversion of Control также является очень хорошим шаблоном, в который можно попасть прямо сейчас, с постоянно увеличивающимися (и блестящими!) Ресурсами, становящимисядоступно для платформы .Net, определенно стоит потратить некоторое время на изучение.

Хотя я еще не изучил полный объем IoC, мне действительно нравится внедрение зависимостей ( тип IoC, если я правильно понимаю, хотя люди, кажется, запутывают IoC / DIсроков довольно много ).На данный момент я лично предпочитаю DI - проект с открытым исходным кодом Ninject , в котором много ресурсов в Интернете и разумный вики-раздел , в котором рассказывается о различных аспектах.

Есть еще много вариантов использования DI и IoC, поэтому я не хочу даже пытаться предоставить вам полный список из-за страха быть обожженным за то, что вы пропустили чью-то любимую.Просто найдите, посмотрите, какой вам нравится, и поиграйте с ним.Обязательно попробуйте пару, если у вас есть время.

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

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

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

Удачи!