Чтобы системы, составляющие совокупность, трудились действеннее, между ними обязан идти обмен информацией. Обмен возможно организовать двумя методами.
1. Все совместно применяемые эти сохраняются в центральной базе данных, доступной всем системам. Модель совокупности, основанная на совместном применении базы данных, довольно часто именуют моделью репозитория.
2. Любая система имеет собственную базу данных. Взаимообмен данными между системами происходит при помощи передачи сообщений.
Большая часть совокупностей, обрабатывающих громадные количества данных, организованы около совместно применяемой базы данных, либо репозитория. Исходя из этого такая модель подойдет к приложениям, в которых эти создаются в одной системе, а употребляются в другой. Примерами могут служить совокупности управления информацией, совокупности автоматического проектирования и CASE-средства.
На рис. 10.2 представлен пример архитектуры интегрированного комплекта CASE-инструментов, основанный на совместно применяемом репозитории. Считается, что для CASE-средств первый совместно применяемый репозитории был создан в первой половине семидесятых годов прошлого века британской компанией ICL в ходе создания собственной операционной системы. Известность эта модель взяла по окончании того, как была применена для помощи разработки совокупностей, написанных на языке Ada. С того времени многие CASE-средства разрабатываются с применением неспециализированного репозитория.
Совместно применяемые репозитории имеют как преимущества, так и недочёты.
1. Разумеется, что совместное применение громадных количеств данных действенно, потому, что не нужно передавать эти из одной системы в другие.
2. Иначе, системы должны быть согласованы с моделью репозитория данных. Это всегда ведет к необходимости компромисса между требованиями, предъявляемыми к каждой системе. Компромиссное ответ может понизить их производительность. В случае если форматы данных новых систем не подходят под согласованную модель представления данных, интегрировать такие системы сложно либо нереально.
3. Системам, в которых создаются эти, не требуется знать, как эти сведенья используются в других системах.
4. Потому, что в соответствии с согласованной моделью данных генерируются громадные количества информации, модернизация таких совокупностей проблематична. Перевод совокупности на новую модель данных будет дорогостоящим и сложным, а иногда кроме того неосуществимым.
5. В совокупностях с репозиторием такие средства, как резервное копирование, обеспечение безопасности, управление доступом и восстановление данных, централизованы, потому, что входят в совокупность управления репозиторием. Эти средства выполняют лишь собственные главные операции и не занимаются вторыми вопросами.
6. Иначе, к различным системам предъявляются различные требования, касающиеся безопасности, резервирования и восстановления данных. В модели репозитория ко всем системам используется однообразная политика.
7. Модель совместного применения репозитория прозрачна: в случае если новые подсистемы совместимы с согласованной моделью данных, их возможно конкретно интегрировать в совокупность.
8. Но сложно разместить репозитории на нескольких автомобилях, потому, что смогут возникнуть неприятности, которые связаны с нарушением и избыточностью целостности данных.
Модель клиент/сервер
Модель архитектуры клиент/сервер — это модель распределенной совокупности, в которой продемонстрировано распределение данных и процессов между несколькими процессорами. Модель включает три главных компонента.
1. Комплект независимых серверов, предоставляющих сервисы вторым системам. Например, сервер печати, что предоставляет услуги печати, файловые серверы, предоставляющие сервисы управления файлами, и сервер-компилятор, что предлагает сервисы по компилированию исходных кодов программ.
2. Комплект клиентов, каковые приводят к сервисам, предоставляемые серверами. В контексте совокупности клиенты являются простыми системами. Допускается параллельное исполнение нескольких экземпляров клиентской программы.
3. Сеть, при помощи которой клиенты приобретают доступ к сервисам. В принципе нет никакого запрета на то, дабы серверы и клиенты запускались на одной машине. На практике, но, модель клиент/сервер в таковой ситуации не употребляется.
Клиенты должны знать имена дешёвых сервисов и серверов, каковые они предоставляют. Одновременно с этим серверам не требуется знать ни имена клиентов, ни их количество. Клиенты приобретают доступ к сервисам, предоставляемым сервером, при помощи удаленного вызова процедур.
самоё важное преимущество модели клиент/сервер пребывает в том, что она есть распределенной архитектурой. Ее действенно применять в сетевых совокупностях с множеством распределенных процессоров. В совокупность легко добавить новый сервер и интегрировать его с другой частью совокупности либо же обновить серверы, не влияя на другие части совокупности. В главе 11 архитектуры распределенных совокупностей рассматриваются более детально.
Repository Pattern with C# and Entity Framework, Done Right | Mosh
