Добрый день!

Такая ситуация — меня пригласили разобраться с проектом в одной конторе. Веб-приложение ASP.NET, но всё намешано в кучу. Я более-менее раскидал сущности по разным уровням, сейчас у меня получается достаточно стандартный проект с тремя уровнями — Data Access Layer, Business Logic Layer, UI. Вопрос возник достаточно принципиальный (для меня ) — что делать со структурами данных? В проекте не используются Strongly-Typed Datasets, а используются свои самописные структуры типа

class Item
{
   public int ID 
   {
       get { return m_ID; }
       set { m_ID = value; }
   }

   // ну и т.п.
}

Я их пока что кинул в чётвертый проект (первые 3 проекта в solution — это 3 уровня) — Entities. И все остальные проекты ссылаются на него. С моей точки зрения это ОК для BLL и UI, но я не уверен, что делать с DAL. 2 вопроса поэтому:

1. Как правильнее — возвращать из DAL в BLL просто DataSet и заставлять BLL самому разбирать датасет, формируя структуры, которые будут использоваться в дальнейшем? Или же прямо в DAL создавать эти структуры?

2. А как сохранять лучше/правильнее — делать "длинный" метод a-la

Save(string name, string address, ...)

или же передавать ту же самую структуру:

Save(Item itemToSave)

?


Спасибо,

Алексей

Здравствуйте, avs99, Вы писали:

A>Я их пока что кинул в чётвертый проект (первые 3 проекта в solution — это 3 уровня) — Entities. И все остальные проекты ссылаются на него. С моей точки зрения это ОК для BLL и UI, но я не уверен, что делать с DAL.

Для рассматриваемого случая разбиение слоёв на отдельные проекты не имеет никакого смысла. Слой — это логическая сущность, проект (сборка) — это единица деплоймента.

A>2 вопроса поэтому:

A>1. Как правильнее — возвращать из DAL в BLL просто DataSet и заставлять BLL самому разбирать датасет, формируя структуры, которые будут использоваться в дальнейшем? Или же прямо в DAL создавать эти структуры?

Прямо в DAL. Преобразование данных в формат приложения — это одна из задач DAL.

A>2. А как сохранять лучше/правильнее — делать "длинный" метод a-la

Как удобнее.

Здравствуйте, avs99, Вы писали:

A>2. А как сохранять лучше/правильнее — делать "длинный" метод a-la

A>

A>Save(string name, string address, ...) 
A>

A>или же передавать ту же самую структуру:

A>

A>Save(Item itemToSave)
A>

A>?

Где-то вычитал такое правило..

Если в коде очень часто параметры идут парами(ну или кортежами из нескольких элементов) по типу

Method1(string name, string address, ...) 
Method2(... ,string name, string address, ...) 
Method3(... ,string name, string address)

То стоит задуматься, не стоит ли выделить их в отдельную сущность. Короче избавляемя от дублирования

Вот еще цитатка из Фаулера на эту тему

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

Но само собой все зависит от ситуации.

Здравствуйте, avs99, Вы писали:

A>или же передавать ту же самую структуру:

A>

A>Save(Item itemToSave)
A>

A>?

Лучше структурой и наглядней и в будущем она ведь может измениться ...

Здравствуйте, IT, Вы писали:

IT>Для рассматриваемого случая разбиение слоёв на отдельные проекты не имеет никакого смысла. Слой — это логическая сущность, проект (сборка) — это единица деплоймента.

Есть маленькое "но". Создание сборки для каждого слоя позволяет явно определить зависимости между слоями и контролировать соблюдение этих зависимостей на этапе компиляции.

Здравствуйте, MaximVK, Вы писали:

MVK>Есть маленькое "но". Создание сборки для каждого слоя позволяет явно определить зависимости между слоями и контролировать соблюдение этих зависимостей на этапе компиляции.
Не.. Зависимость между слоями как раз довольно просто отслеживается, а вот внутри слоя, при таком подходе, возникает полная каша из "горизонтальных" зависимостей, различные аспекты так между собой связываются, что вспотеешь распутывать... Поэтому если уж делить на сборки, то я предпочитаю "вертикально" по принципу принадлежности к одному аспекту (компоненту/сервису). Так гораздо проще контролировать связи между сервисами и избегать лишних зависимостей.

Здравствуйте, MaximVK, Вы писали:

MVK>Есть маленькое "но". Создание сборки для каждого слоя позволяет явно определить зависимости между слоями и контролировать соблюдение этих зависимостей на этапе компиляции.

Безусловно, во всём можно найти как плюсы, так и минусы. Но, если одно приложение, например, веб-сайт состоит из 25-ти сборок, которые больше нигде и никем не используются, то, по-моему, это перебор. Это если большое приложение. А если маленькое, 2-3 странички. Для них у тебя будет 4-5 проектов?

"Хороший" пример в этом смысле .NET Pet Shop 4.0. 11 веб-страниц и 22 проекта. Загрузи как-нибудь и посмотри, много ли в этом смысла.

Здравствуйте, MaximVK, Вы писали:

IT>>Для рассматриваемого случая разбиение слоёв на отдельные проекты не имеет никакого смысла. Слой — это логическая сущность, проект (сборка) — это единица деплоймента.

MVK>Есть маленькое "но". Создание сборки для каждого слоя позволяет явно определить зависимости между слоями и контролировать соблюдение этих зависимостей на этапе компиляции.

Кому-как Неокторые и не чураются из презентера на клиенте обратиться (добавить reference) к DAL-сборке для получения данных, если не найдут подходящего метода в сервисе То есть не спасает

А контролировать такие вещи на этапе компиляции (пост-компиляции) можно и другими средствами.

IT>"Хороший" пример в этом смысле .NET Pet Shop 4.0. 11 веб-страниц и 22 проекта. Загрузи как-нибудь и посмотри, много ли в этом смысла.

Да, посмотри на PetShop. В нем насколько я помню все бизнес-сущности вынесены в проект Model, на который идут ссылки из DAL, BLL, UI

A>2. А как сохранять лучше/правильнее — делать "длинный" метод a-la

A>

A>Save(string name, string address, ...) 
A>

A>или же передавать ту же самую структуру:

A>

A>Save(Item itemToSave)
A>

A>?

конечно структурой
представь ситуацию — завтра нужно будет добавить атрибут ZipCode — либо менять сигнатуру всех интерфейсов/методов, либо просто добавить property в объекте Item

Здравствуйте, grinevi, Вы писали:

IT>>"Хороший" пример в этом смысле .NET Pet Shop 4.0. 11 веб-страниц и 22 проекта. Загрузи как-нибудь и посмотри, много ли в этом смысла.

G>Да, посмотри на PetShop. В нем насколько я помню все бизнес-сущности вынесены в проект Model, на который идут ссылки из DAL, BLL, UI

В этом проекте абсолютно всё вынесено в отдельные dll. Хороший пример маразма.