Интерфейсы на различных логических слоях

@Ice^^Heat:

Что Вы подразумеваете под этим, уровень данных не должен знать об уровне бизнес-логики? Как Вы заполнили бы бизнес-объект данными?

UI спрашивает ServiceClass в бизнес-уровне для сервиса, а именно, получая список объектов, фильтрованных объектом с необходимыми данными параметра.
Затем ServiceClass создает экземпляр одного из классов репозитория в уровне данных и называет GetList (фильтры ParameterType).
Затем уровень данных получает доступ к базе данных, тянет данные и отображает его на распространенный формат, определенный в "доменном" блоке.
BL больше не имеет работы, чтобы сделать с этими данными, таким образом, это производит его к UI.

Затем UI хочет отредактировать Объект X. Это отправляет объект (или бизнес-объект) в службу в Бизнес-Уровне. Бизнес-уровень проверяет объект, и если он в порядке, он отправляет, он к данным разделяет на уровни для устройства хранения данных.

UI знает сервис в бизнес-уровне, который снова знает об уровне данных.

UI ответственен за отображение пользовательского ввода данных к и от объектов, и уровень данных ответственен за отображение данных в дб к и от объектов. Бизнес-уровень остается чисто бизнес-.:)

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

То, что я делаю, использовать Разработку через тестирование, таким образом, я пишу свои уровни UI и Model сначала, и уровень Data дразнят, таким образом, UI и модель являются сборкой вокруг зависящих от домена объектов, затем позже я отображаюсь, они возражают против того, что когда-либо технология я использую Слой Данных. Очень плохая идея состоит в том, чтобы позволить базе данных определить дизайн Вашего приложения, записать приложение сначала и думать о данных позже.

PS заголовок вопроса немного вводит в заблуждение

Это могло быть решение, поскольку это не разрушит интерфейс. Я предполагаю, что у Вас мог быть класс как это:

public class BusinessObjectRecord : BusinessObject
{
}

Я всегда создаю отдельный блок, который содержит:

• Много маленьких Интерфейсов (думают ICreateRepository, IReadRepository, IReadListRepsitory.. список продолжается, и большинство из них полагается в большой степени на дженерики),
• Много конкретных Интерфейсов, как IPersonRepository, который наследовался IReadRepository, Вы понимаете..
  Что-либо, что Вы не можете описать только с меньшими интерфейсами, Вы помещаете в конкретный интерфейс.
  Пока Вы используете IPersonRepository для объявления объекта, Вы заставляете чистый, последовательный интерфейс работать с. Но строка над заголовком, можно также сделать класс, который берет f.x. ICreateRepository в его конструкторе, таким образом, код закончит тем, что был очень легок сделать некоторый действительно броский материал с. Существуют также интерфейсы для Сервисов в бизнес-уровне здесь.
• Наконец я засовываю все объекты области в дополнительный блок, только для создания самой кодовой базы немного более чистой и более слабо связанной. Эти объекты не имеют никакой логики, они - просто распространенный способ описать данные для всех 3 + слои.

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

Что Вы подразумеваете под этим, уровень данных не должен знать об уровне бизнес-логики? Как Вы заполнили бы бизнес-объект данными?

Я часто делаю это:

namespace Data
{
    public class BusinessObjectDataManager
    {
         public void SaveObject(BusinessObject object)
         {
                // Exec stored procedure
         {
    }
}

Можно хотеть разделить интерфейсы на два типа, а именно:

• Интерфейсы представления - которые являются интерфейсами, которые указывают Ваши взаимодействия с Вашим UI, и
• Интерфейсы передачи данных - которые являются интерфейсами, которые позволят Вам указывать взаимодействия со своими данными

Возможно наследовать и реализовать оба набора интерфейсов, таким образом что:

public class BusinessObject : IView, IData

Таким образом, в Ваших данных разделяют на уровни, только необходимо видеть интерфейсную реализацию IData, в то время как в UI только необходимо видеть интерфейсную реализацию IView.

Другая стратегия, которую Вы могли бы хотеть использовать, состоит в том, чтобы составить Ваши объекты в уровнях UI или Data, таким образом, что они просто используются этими слоями, например,

public class BusinessObject : DomainObject

public class ViewManager<T> where T : DomainObject

public class DataManager<T> where T : DomainObject

Это в свою очередь позволяет Вашему бизнес-объекту оставаться незнакомым с уровнем UI/View и о слоем данных.

Таким образом, проблема состоит в том, что бизнес-слой должен подвергнуть больше функциональности слою данных, и добавляющий это, функциональность означает подвергать слишком много уровню UI? Если я понимаю Вашу проблему правильно, она кажется, что Вы пытаетесь удовлетворить слишком много единственным интерфейсом, и это просто заставляет ее становиться нарушенной. Почему бы не два интерфейса на бизнес-слой? Можно было бы быть простым, безопасным интерфейсом для уровня UI. Другой был бы интерфейс низшего уровня для слоя данных.

Можно применить этот подход с двумя интерфейсами к любым объектам, которые должны быть переданы и UI и слоям данных, также.

public class BusinessLayer : ISimpleBusiness
{}

public class Some3LayerObject : ISimpleSome3LayerObject
{}

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

Я думаю, что многие разработчики думают о базе данных как о простом слое персистентности для их объектов и только обеспокоены в операциях CRUD, что тем объектам нужно. Слишком много усилий прикладывается к "несоответствию импеданса" между объектными и реляционными моделями. Вот идея: прекратите пробовать.

Запишите хранимые процедуры для инкапсуляции данных. Используйте наборы результатов, DataSet, DataTable, SqlCommand (или java/php/whatever эквивалент) по мере необходимости из кода для взаимодействия с базой данных. Вам не нужны те объекты. Превосходный пример встраивает SqlDataSource в.ASPX страницу.

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

Объектно-реляционные картопостроители являются дьяволом. Прекратите использовать их.

Создание корпоративных приложений часто является упражнением в руководящей сложности. Необходимо сохранить вещи максимально простыми, или у Вас будет абсолютно неудобная в сопровождении система. Если Вы готовы позволить некоторую связь (который свойственен от любого приложения так или иначе), можно покончить и слоем бизнес-логики и с уровнем доступа к данным (заменяющий их хранимыми процедурами), и Вам не будет нужен ни один из тех интерфейсов.