Передача данных между бизнес-уровнем и уровнем доступа к данным - плохой код?

Я использую следующий код в классе JCProperty для извлечения данных из DAL:

Dim x As JCProperty
        x = JCPropertyDB.GetProperty(PropertyID)

        If Not x Is Nothing Then
            Me.PropertyID = x.PropertyID
            Me.AddressLine1 = x.AddressLine1
            Me.AddressLine2 = x.AddressLine2
            Me.AddressLine3 = x.AddressLine3
            Me.AddressCity = x.AddressCity
            Me.AddressCounty = x.AddressCounty
            Me.AddressPostcode = x.AddressPostcode
            Me.TelNo = x.TelNo
            Me.UpdatedOn = x.UpdatedOn
            Me.CreatedOn = x.CreatedOn
            Me.Description = x.Description
            Me.GUID = x.GUID
        End If

Это работает нормально, но требует, чтобы объект DAL (JCPropertyDB) знал о бизнес-объекте (JCProperty), и я эффективно создаю и заполняю один и тот же объект дважды (один раз в DAL, чтобы вернуться к BL, а затем снова внутри объекта BL для заполнения сам).

Мне что-то здесь не хватает, я знаю, что должен быть способ получше!

Фактически мне нужно назначить «Me = x», что запрещено. Кто-нибудь может меня поправить?


.net vb.net data-access-layer
person Simon    schedule 11.10.2008    source источник

Ответы (5)


arrow_upward
1
arrow_downward

Лично я ленивый. Обычно я делаю что-то вроде:

class JCProperty : inherits JCPropertyDB
   {

   New()
      {
      MyBase.New()

      GetProperty(PropertyID)

      }
   }

В общем, все готово, пока у вас не появятся некоторые дополнительные функции в классе JCProperty, которые должны выполняться «поверх» функций, уже существующих в JCPropertyDB. Затем вы переопределяете методы JCPropertyDB, чтобы сначала вызвать базовый метод, а затем добавить новую функциональность.

Рон

person Ron Savage    schedule 11.10.2008
comment
Именно то, чего мне не хватало! Ваше здоровье. - person Simon; 11.10.2008

arrow_upward
4
arrow_downward

Вы находитесь на правильной линии, но немного упускаете одну точку.

Обычно уровень доступа к данным (DAL) возвращает объекты передачи данных (DTO) из вашей базы данных. . Это простые старые объекты CLR (POCO), которые не содержат бизнес-логики, а просто свойства, более или менее сопоставленные с таблицами базы данных.

Тогда у вас будет код, который создает модель домена из этих DTO, называемую Data Mapper. Классы в модели домена могут иметь похожие имена (например, CustomerDTO -> Customer), но в дополнение к данным они будут содержать правила проверки и, возможно, другую бизнес-логику.

Именно эту модель предметной области вы затем используете на своем бизнес-уровне, а не фактические DTO. Это означает, что если вы изменяете DTO, возвращаемые из DAL (то есть путем реализации нового инструмента ORM), вам нужно только изменить свой Data Mapper при условии, что модель данных останется прежней.

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

person Neil Barnwell    schedule 14.10.2008

arrow_upward
2
arrow_downward

Не уверен, что это ответит на ваш вопрос, но важно то, что модель предметной области не зависит от отображения и хранения. Это часто обозначается как разделение интересов. Идея состоит в том, чтобы ослабить связи и создать простую систему, в которой объекты не имеют нескольких совершенно разных функций.
Итак, что бы я сделал, так это разрешил бы DAL создавать бизнес-объекты напрямую, но следил, чтобы я не загрязнял свои бизнес-объекты чем-либо, связанным с DAL. Точно так же я не хочу загрязнять их специфичными для пользовательского интерфейса вещами, такими как HTML. На мой взгляд, нормально, что и бизнес-уровень, и DAL, и уровень пользовательского интерфейса имеют зависимости от модели предметной области, однако недопустимо иметь зависимости от модели предметной области и от этих других компонентов.
Чтобы ослабить связи, используйте что-то Spring или любой другой контейнер для инъекций зависимостей вместе с интерфейсами и проводкой может вам помочь.
Создавая один и тот же объект на каждом уровне, вы нарушаете принцип DRY (не повторяйтесь), вводите код котельной пластины и увеличиваете шанс внести где-нибудь ошибку.

person Erlend    schedule 11.10.2008

arrow_upward
0
arrow_downward

Проверьте: http://www.icemanind.com/layergen.aspx

person Icemanind    schedule 29.09.2009

arrow_upward
0
arrow_downward

Я принимал БО и отправлял обратно БО из DAL через шаблон моста и модель провайдера. Я не понимаю смысла DTO, если я не опасаюсь тяжелой сериализации (скажем, веб-службы или JSON). Мой подход заключался в абстрагировании уровня данных и бизнес-уровня через интерфейс и предоставлении уровня анонимных данных, вводимого в бизнес-объект. Это означает, что я могу подключить любой уровень данных, реализовать интерфейс с универсальными методами загрузки и сохранения, который затем будет доступен через уровень моего домена. В BL нет кода DAL - просто вызов предоставленного и абстрактного уровня данных. Мой вызов уровня данных управляется шаблоном поставщика (без прямой ссылки), и я просто делаю:

public class Person : IBusinessObject<Person>
{
   protected IDataLayer<T> dataLayer;

   Person Load() { this.dataLayer.Load(this); }

}

на уровне данных у меня есть ...

public class PersonMapper : IDataLayer<Person> 
{
    Person Load(Person person) {
    ...get DB stuff...map to person...decorate object...
       return person;
    }
}

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

person Community    schedule 09.10.2009