использование системы; MVC Storefront - Роб Конери справиться сложно?

Question

Я слежу за видеопрограммой StoreFront MVC Application, созданной Робом Конери.Я заметил, что Commerce.MVC.Web ссылается как на Commerce.MVC.Data, так и на Commerce.MVC.Services.Это потому, что Commerce.MVC.Web нуждается в Commerce.MVC.Data из-за сущностей, определенных в нем.Как лучше ссылаться только на Commerce.MVC.Services.Нужно ли помещать сущности в службу или какие-либо предложения?

Жирный текст взят из Commerce.MVC.Data:

Commerce.MVC.Data
Commerce.MVC.Services- reference the Commerce.MVC.Data
Commerce.MVC.Web - reference both the Commerce.MVC.Data and Commerce.MVC.Services

Вот пример кода из CatalogController:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using Commerce.MVC.Data;
using Commerce.MVC.Services;

namespace Commerce.MVC.Web.Controllers {
    public class CatalogController : Controller {

        #region .ctor
        ICatalogService _catalogService;

        public CatalogController(ICatalogService catalogService) {
            _catalogService = catalogService;
        }

        #endregion  

        #region ViewData
        /// <summary>
        /// Class used for transferring data to the View
        /// </summary>
        public class CatalogData {

            public CatalogData() { }
            public CatalogData(List<Category> categories, Category parent, Category child) {
                this.Categories = categories;
                this.Category = parent;
                this.SubCategory = child;
            }

            public IList<Category> Categories;

           //The below is came from Commerce.NVC.Data

            public Product Product { get; set; }
            public Category Category { get; set; }
            public Category SubCategory { get; set; }
        }
        #endregion
}
}

Answer 1

Отредактированный ответ ...

Вы можете использовать Службу очень хорошо, но служба возвращает что-то и что что-то - это ваша сущность.Чтобы ваше веб-приложение могло использовать эти сущности, оно должно ссылаться на класс, содержащий сущности, верно?

Теперь вы можете обойти это, возвращая анонимные типы или, возможно, создавая собственные DTO - но тогда вы теряете проверкии все, что заявило об этом субъект.По сути - вы дублируете свой код.

Вы это видите?

Answer 2

Я не думаю, что это имеет большое значение (без каламбура), но мы обычно разделяем сущности в сборку модели, которая является общей для всех слоев.

Итак, наша структура:

Company.Project.Model Company.Project.Infrastructure

Company.Project.Web Company.Project.Services Company.Project.Data

На модель и инфраструктуру (сквозные задачи) ссылаются во всех слоях, а Web / Services / Data могут общаться только со слоем, расположенным ниже.

Надеюсь, что это имеет смысл.

Answer 3

Я отправил этот же вопрос Робу около года назад, и его ответ заставил меня понять, что я путаю физическое разделение кода с логическим разделением с использованием пространств имен.

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

Answer 4

Я думаю, что архитектура в приложении Роба в порядке.

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

Однако, если ваш веб-сайт настроен с использованием структуры внедрения зависимостей, вы не увидите экземпляры классов доступа к данным.

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

Именно поэтому проекты всегда должны иметь обзоры кода. :)