Книжное предложение на этом понятии DDD, характерном для ASP.NET MVC и JSON? [закрытый]
Я ищу книгу или запись в блоге на следующих понятиях DDD, чем-то характерном для кода C# и MVC. Быстрая сводка: частично заполненные модели предметной области из специальных методов репозитория и отправки только измененных свойств модели предметной области как JSON назад от клиента.
Подробнее:
Если бы Вы сделали, чтобы Клиент возразил, но нуждался в выпадающем списке, имеющем только клиентское число и имя клиента, Вы создали бы специальный метод Репозитория, чтобы возвратить полный IList Клиента, но только заполнить идентификатор клиента и Имя клиента, оставив другие свойства пустыми или пустыми. Это сохраняет тонны создания специальных классов для модели представления.
При редактировании Клиента Вы кэшировали бы Клиентский объект в переменной сеанса в сервере затем, JSON сериализируют Модель Представления, содержащую Клиента DDL и первый клиентский объект для клиента, возможно встраивая JSON в первый HTML, прибывающий из сервера. Было бы действительно хорошо иметь твердость JSON к методу контроллера MVC "параметры объекта" (повторная сборка данных сообщения к параметру объекта от JSON).
Клиент (JavaScript) инстанцирует клиентского объекта и связывает свойства объектов с соответствующими операторами ввода HTML того же имени. Когда каждый изменяется, другие изменения. Также добавьте шаблонное понятие для объектов IList. Это также отмечает клиентское свойство объекта как грязное, когда входное значение изменяется (событие).
На отправляют, только измененные (грязные) свойства объектов сериализированы к JSON и переданы обратно серверу. Неизменные свойства просто не учтены. Сервер объединится, кэшируемый клиентский объект с частичным клиентским объектом JSON (изменяется только), отправляя получающийся Клиентский объект репозиторию для сохранения.
Это - действительно большое понятие. Я хотел бы читать о теории и получить список ожидающих выполнения задач.
1 ответ
(Я не даю рекомендации по книгам. Я отправляю ответ только потому, что у меня закончилось место в поле для комментариев).
Я не думаю, что этот «шаблон» имеет какое-то отношение к DDD, но все это звучит так привлекательно, не так ли?
Я должен сказать, однако, что это кричит: «Я буду так долго и упорно работать над этой потрясающей структурой, которая в конечном итоге принесет мало или совсем не улучшит производительность, но я вставлю ее в свое приложение, потому что Я потратил на это так много времени ". Либо это, либо попытка реализовать это предотвратит фактическую реализацию приложения.
Привязка модели ASP.NET MVC делает многое из того, к чему вы стремитесь, хотя и не совсем так, как вы описываете. Чего он не делает, так это бита «только отправлять обратно грязные свойства», но, честно говоря, любое веб-приложение, которое получит от этого выгоду после того, как вся логика на стороне клиента, скорее всего, плохо спроектирована на другом уровне ( данные не выгружаются; отдельные просмотры слишком тяжелы).
Я не вижу никакой пользы от кеширования объекта в сеансе, и в любом случае это анафема для системы ASP.NET MVC.
Загрузка только необходимых объектов / коллекций из репозитория - это решенная проблема с использованием первоклассной технологии объектно-реляционного сопоставления, такой как NHibernate.
Сохраните JSON для асинхронных операций.
Помимо всего этого, то, что вы описываете, можно в общих чертах рассматривать как набор оптимизаций, которые могут быть реализованы по частям после того, как ядро приложения заработает. Это гарантирует, что вы предоставите некоторую ценность и выполните существенную работу по реализации этих оптимизаций (если они даже окажутся таковыми), если производительность будет неприемлемой.