Re[12]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.12.10 20:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Чушь. Я вот как ни кручу, у меня не получается ссылки на dal как ты расписывал


G>>Show Me The Code. Я тебе покажу ссылку.


I>Обычная модель графа — граф, узлы, ребра.


Меня как всегда интересуют методы, а тебя "предметная область".

Так покажи каким сущностям предметной области соответствует твой граф, и скажи что за метод в любой сущности использует связанные.
Re[13]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.12.10 20:26
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Обычная модель графа — граф, узлы, ребра.


G>Меня как всегда интересуют методы, а тебя "предметная область".


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


граф — сеть. узел — узел. ребро — линия связи.

Твоя формула "Есть класс A, который содержит некоторые данные описывающие предметную область, и метод B, реализующий некоторую функцию.
Функция в свою очередь обращается к другим данным (когда не обращается — нам неинтересно). То есть в A должна быть ссылка на DAL, tesability идет лесом и получается каша.
"

А = граф. Б — метод графа, например IsConnected, возвращает связный ли граф. Другие данные — вершины и ребра.

Итого — никаких ссылок на DAL не нужна.
Re[14]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.12.10 20:37
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Обычная модель графа — граф, узлы, ребра.


G>>Меня как всегда интересуют методы, а тебя "предметная область".


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


I>граф — сеть. узел — узел. ребро — линия связи.


I>Твоя формула "Есть класс A, который содержит некоторые данные описывающие предметную область, и метод B, реализующий некоторую функцию.

I>Функция в свою очередь обращается к другим данным (когда не обращается — нам неинтересно). То есть в A должна быть ссылка на DAL, tesability идет лесом и получается каша.
I>"

I>А = граф. Б — метод графа, например IsConnected, возвращает связный ли граф. Другие данные — вершины и ребра.


I>Итого — никаких ссылок на DAL не нужна.


Ты грузишь весь граф из хранилища в память?

Ну для начала. Думаю у графа есть значительно больше методов, чем IsConnected. Например возьмем простые и насущные: отображение
1)Список всех узлов.
2)Список всех линий.

Как они в такой модели решаться будут?

Ну покажи код, я прям потыкаю.
Re[3]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 00:00
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Сваливание логики и данных в одну кучу приводит к прогибанию структуры данных под текущие требования. Поддерживать получившееся месиво — занятие крайне неблагодарное.


Нет никакого сваливания в кучу

S>2. Данные должны быть отделены от бизнес-логики.


Это и ежу понятно. Речь о том, что Domain model это модель данных + бизнес-логика.
Re[15]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 00:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Итого — никаких ссылок на DAL не нужна.


G>Ты грузишь весь граф из хранилища в память?


Могу грузить, могу не грузить. В модели, сервисах нет никаких ссылок на DAL.

G>Ну для начала. Думаю у графа есть значительно больше методов, чем IsConnected. Например возьмем простые и насущные: отображение

G>1)Список всех узлов.
G>2)Список всех линий.

G>Как они в такой модели решаться будут?


Очень просто, путём итерации по коллекции.

G>Ну покажи код, я прям потыкаю.


Ты отказался не то что код показать, а даже мало мальски пояснить свою идею.

Все что я сейчас делаю — заставляю тебя пояснять твою же идею
Re[16]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.12.10 08:13
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Итого — никаких ссылок на DAL не нужна.


G>>Ты грузишь весь граф из хранилища в память?

I>Могу грузить, могу не грузить. В модели, сервисах нет никаких ссылок на DAL.
Покажи уже код.

G>>Ну для начала. Думаю у графа есть значительно больше методов, чем IsConnected. Например возьмем простые и насущные: отображение

G>>1)Список всех узлов.
G>>2)Список всех линий.
G>>Как они в такой модели решаться будут?
Запросом, Linq с проекцией.

I>Очень просто, путём итерации по коллекции.

А откуда коллекция берется?

G>>Ну покажи код, я прям потыкаю.

I>Ты отказался не то что код показать, а даже мало мальски пояснить свою идею.
I>Все что я сейчас делаю — заставляю тебя пояснять твою же идею
Да ты теперь увиливаешь. У тебя вообще нигде ссылок на dal нету, данные из воздуха появляются.

Вот давай возмем 3 юзкейса:
1)Проверка свзяности графа
2)Получение списка узлов
3)Получение списка ребер

И покажи код, который эффективно, с точки зрения трудозатрат и скорости работы, релизует эти юзкейсы.

Вот мой вариант:

public class GraphService
{
    IRepository<Vertex> verticesRepo;
    IRepository<Edge> edgesRepo;

    public GraphService(IRepository<Vertex> verticesRepo,
                        IRepository<Edge> edgesRepo)
    {
        this.verticesRepo = verticesRepo;
        this.edgesRepo = edgesRepo;
    }
 
    public bool IsGraphConnected(int graphId)
    {
        var q = from v in verticesRepo.Items()
                where v.GraphId == graphId
                select v;
        return IsConnected(AdjancedNodes(q)); 
    }

    public IQueryable<Vertex> ListVertivcies()
    {
        return verticesRepo.Items();
    }

    public IQueryable<Edge> ListVertivcies()
    {
        return edgesRepo.Items();
    }

    private ILookup<int,int> AdjancedNodes(IQueryable<Vertex> q)
    {
        return (from v in q
                from e in v.Edges
                select new {Left = v.Id, Right = e.ToId};
               .ToLookup(p => p.Left, p => p.Right);
    }

    private bool IsConnected(ILookup<int,int> adjancedNodes)
    {
        //skipped
    }
}


Модель данных:
public class Graph
{
    public int Id { get; set; }
    public ICollection<Vertex> Verticies { get; set; }
    //...
}

public class Vertex
{
    public int Id { get; set; }
    public int GraphId { get; set; }
    public Graph Graph { get; set; }

    public ICollection<Edge> Edges { get; set; }
    private ICollection<Edge> Edges1 { get; set; } //Для маппинга ассоциаций
    //...
}

public class Edge
{
    public int Id { get; set; }
    public int FromId { get; set; }
    public int ToId { get; set; }

    public Vertex From { get; set; }
    public Vertex To { get; set; }
    //...
}


Ты утверждаешь что можешь внести IsGraphConnected внутрь метода Graph без уменьшения эффективности программы и увеличения писанины.
Покажи как это сделать.
Re: Обращение к бизнеслогике приложения из сущности.
От: Аноним  
Дата: 24.12.10 11:53
Оценка:
Здравствуйте, testarch, Вы писали:

T>Подскажите насколько правильно/не правильно обращаться бизнеслогике приложения из сущности.


Имхо неправильно, т.к. сущности ничего не должны знать о бизнес логике, т.к. поведение все же должно быть локализовано в слое бизнес логики. С другой стороны часто нужен механизм реагирования на изменения состояния сущностей (скорее всего не всех, а каких-то конкретных). Этот механизм легко реализуется используя шаблон обратной зависимости.
Re[17]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 12:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Ты грузишь весь граф из хранилища в память?

I>>Могу грузить, могу не грузить. В модели, сервисах нет никаких ссылок на DAL.
G>Покажи уже код.

40мб ?

I>>Очень просто, путём итерации по коллекции.

G>А откуда коллекция берется?

Создается в рантайме некоторым алгоритмом. Этим алгоритмом может быть как известный тебе cost based mesh design , так и import, load и тд.

I>>Все что я сейчас делаю — заставляю тебя пояснять твою же идею

G>Да ты теперь увиливаешь. У тебя вообще нигде ссылок на dal нету, данные из воздуха появляются.

Почему же нигде. Модель и BL про DAL ничего не знают, но это ж не значит что нигде не этот DAL нет ссылок

G>Вот давай возмем 3 юзкейса:

G>1)Проверка свзяности графа
G>2)Получение списка узлов
G>3)Получение списка ребер

G>И покажи код, который эффективно, с точки зрения трудозатрат и скорости работы, релизует эти юзкейсы.


Эффективно для абстрактного приложения или для конкретного ?

G>Вот мой вариант:


G>
G>public class GraphService
G>{
G>    private bool IsConnected(ILookup<int,int> adjancedNodes)
G>    {
G>        //skipped
G>    }
G>}
G>


Ты показал вcе что угодно, кроме IsConnected. Где проверка достижимости узлов ?

G>Ты утверждаешь что можешь внести IsGraphConnected внутрь метода Graph без уменьшения эффективности программы и увеличения писанины.

G>Покажи как это сделать.

Для начала давай определимся, пример для абстрактного приложения или для конкретного ?

Абстрактный случай я оставлю тебе, ты по ним большой специалист.

Ты взахлёб рассказываешь про дизайне, но при этом даже не поинтересовался, зачем нужен этот метод IsConnected.

Если я скажу, что IsConnected используется как для валидации внутри модели(модель реактивная и умеет себя валидировать) так и для некоторых операций над моделью, ты сильно удивишься ?
Re[2]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 12:47
Оценка:
Здравствуйте, Аноним, Вы писали:

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


Бизнес-логика понятие сильно растяжимое
Re[18]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.12.10 13:01
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


G>>>>Ты грузишь весь граф из хранилища в память?

I>>>Могу грузить, могу не грузить. В модели, сервисах нет никаких ссылок на DAL.
G>>Покажи уже код.
I>40мб ?
Не увиливай, я тебе пример дал на одну страницу, ты тоже можешь показать пример аналогичного размера.


I>>>Очень просто, путём итерации по коллекции.

G>>А откуда коллекция берется?
I>Создается в рантайме некоторым алгоритмом. Этим алгоритмом может быть как известный тебе cost based mesh design , так и import, load и тд.
Алгоритм откуда данные берет? Тоже из воздуха?

I>>>Все что я сейчас делаю — заставляю тебя пояснять твою же идею

G>>Да ты теперь увиливаешь. У тебя вообще нигде ссылок на dal нету, данные из воздуха появляются.
I>Почему же нигде. Модель и BL про DAL ничего не знают, но это ж не значит что нигде не этот DAL нет ссылок
Ты опять увиливаешь.

G>>Вот давай возмем 3 юзкейса:

G>>1)Проверка свзяности графа
G>>2)Получение списка узлов
G>>3)Получение списка ребер

G>>И покажи код, который эффективно, с точки зрения трудозатрат и скорости работы, релизует эти юзкейсы.

I>Эффективно для абстрактного приложения или для конкретного ?
Да неважно, самая затратная операция у тебя всегда будет одна при таких юзкейсах. Это доставание из базы.

G>>Вот мой вариант:


G>>
G>>public class GraphService
G>>{
G>>    private bool IsConnected(ILookup<int,int> adjancedNodes)
G>>    {
G>>        //skipped
G>>    }
G>>}
G>>


I>Ты показал вcе что угодно, кроме IsConnected. Где проверка достижимости узлов ?

Да простым breadth-first его сделать, это к вопросу архитектуры никак не относится.

G>>Ты утверждаешь что можешь внести IsGraphConnected внутрь метода Graph без уменьшения эффективности программы и увеличения писанины.

G>>Покажи как это сделать.
I>Для начала давай определимся, пример для абстрактного приложения или для конкретного ?
См выше.

I>Ты взахлёб рассказываешь про дизайне, но при этом даже не поинтересовался, зачем нужен этот метод IsConnected.

Это сейчас меня не интересует. Меня интересует как писать код в данном случае.
Ты показать не можешь, пытаешься увиливать. Продолжай в том же духе и с тобой вообще никто общаться не будет.

I>Если я скажу, что IsConnected используется как для валидации внутри модели(модель реактивная и умеет себя валидировать) так и для некоторых операций над моделью, ты сильно удивишься ?

Абсолютно без разницы. См выше.
Re[3]: Обращение к бизнеслогике приложения из сущности.
От: Аноним  
Дата: 24.12.10 13:38
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Аноним, Вы писали:


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


I>Бизнес-логика понятие сильно растяжимое


Конечно, но системы надо структурировать единообразно.
Re[19]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 14:10
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Покажи уже код.

I>>40мб ?
G>Не увиливай, я тебе пример дал на одну страницу, ты тоже можешь показать пример аналогичного размера.

Ты уже показал необходимый минимум с той разницей что мне не нужен Service в конкретном случае.

I>>Создается в рантайме некоторым алгоритмом. Этим алгоритмом может быть как известный тебе cost based mesh design , так и import, load и тд.

G>Алгоритм откуда данные берет? Тоже из воздуха?

Алгоритм берет данные из своих параметров А параметры ему передает например cкрипт или код примерно такого вида:

var algEngine = container.Resolve<IAlgorithmManager>();
var loader = container.Resolve<ILoader>(connection); 

var newModel = algEngine.Apply(loader, oldModel);


I>>Почему же нигде. Модель и BL про DAL ничего не знают, но это ж не значит что нигде не этот DAL нет ссылок

G>Ты опять увиливаешь.

Тебе вероятно непонятно как можно жить без ссылок на DAL внутри модели и BL

G>>>И покажи код, который эффективно, с точки зрения трудозатрат и скорости работы, релизует эти юзкейсы.

I>>Эффективно для абстрактного приложения или для конкретного ?
G>Да неважно, самая затратная операция у тебя всегда будет одна при таких юзкейсах. Это доставание из базы.

Конечно. При этом она не имеет никакого отношения к бизнес-задаче. Поэтому она вынесена во внешний функционал, т.е. в инфраструктура.

Вот в этой инфраструктуре и будут ссылки на DAL.

I>>Ты показал вcе что угодно, кроме IsConnected. Где проверка достижимости узлов ?

G>Да простым breadth-first его сделать, это к вопросу архитектуры никак не относится.

Так и пиши — BFS, и не надо лепить порожние Linq-выражения.

I>>Ты взахлёб рассказываешь про дизайне, но при этом даже не поинтересовался, зачем нужен этот метод IsConnected.

G>Это сейчас меня не интересует. Меня интересует как писать код в данном случае.

Вообще то должно интересовать, если ты хочешь поместить этот метод в правильное место. А особенно важно, если ты хочешь добиться того, что бы и другие девелоперы помещали методы в правильных местах, а не где попало.

I>>Если я скажу, что IsConnected используется как для валидации внутри модели(модель реактивная и умеет себя валидировать) так и для некоторых операций над моделью, ты сильно удивишься ?

G>Абсолютно без разницы. См выше.

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

Имеем следующее — метод IsConnected

1 зависит исключительн от внутренностей Graph 2 зависит исключительно от сущностей которые не существуют вне Graph, т.е. graph управляет временем жизни этих объхектов

Следовательно, это равносильно тому, что IsConnected зависит исключительно от Graph.

Итого у класса Graph будет метод IsConnected который будет выполнять BFS над коллекциями узлов и ребер.

Что бы поднять IsConnected на уровень выше, в BL, нужно иметь существенные основания.

При том минимуме что я показал, в этом нет необходимости.

Могу показать, какие будут изменение при введении новых требований, если хочешь.
Re[4]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 14:12
Оценка:
Здравствуйте, Аноним, Вы писали:

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


I>>Бизнес-логика понятие сильно растяжимое


А>Конечно, но системы надо структурировать единообразно.


Единообразно это касается подхода или же дизайна ?

Если подхода — "выявить важнейшие требования и на этом основании предложить конкретную структуру", то я согласен.

А если единообразно это "у разных моделей должна быть одинаковая структура" то это к доктору.

Вот gangjustas все хочет убедить меня, что модель данных или BL просто обязаны иметь ссылку на DAL
Re[5]: Обращение к бизнеслогике приложения из сущности.
От: Аноним  
Дата: 24.12.10 14:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Единообразно это касается подхода или же дизайна ?


И того и другого, но конечно по мере сил

I>А если единообразно это "у разных моделей должна быть одинаковая структура" то это к доктору.


Я бы сказал — узнаваемая и привычная структура

I>Вот gangjustas все хочет убедить меня, что модель данных или BL просто обязаны иметь ссылку на DAL


Думаю вы о разных вещах говорите, в роли DAL например WCF может быть использован...
Re[6]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 15:14
Оценка:
Здравствуйте, Аноним, Вы писали:

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


I>>Единообразно это касается подхода или же дизайна ?


А>И того и другого, но конечно по мере сил


I>>А если единообразно это "у разных моделей должна быть одинаковая структура" то это к доктору.


А> Я бы сказал — узнаваемая и привычная структура


I>>Вот gangjustas все хочет убедить меня, что модель данных или BL просто обязаны иметь ссылку на DAL


А>Думаю вы о разных вещах говорите, в роли DAL например WCF может быть использован...


Конечно может. Но это не значит что в модели и BL будет ссылка на этот DAL
Re[20]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.12.10 16:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Создается в рантайме некоторым алгоритмом. Этим алгоритмом может быть как известный тебе cost based mesh design , так и import, load и тд.

G>>Алгоритм откуда данные берет? Тоже из воздуха?

I>Алгоритм берет данные из своих параметров А параметры ему передает например cкрипт или код примерно такого вида:


I>
I>var algEngine = container.Resolve<IAlgorithmManager>();
I>var loader = container.Resolve<ILoader>(connection); 

I>var newModel = algEngine.Apply(loader, oldModel);
I>


Вот прекрасно, а скрипт этот где находится?
и приведи контракты IAlgorithmManager и ILoader.

I>>>Почему же нигде. Модель и BL про DAL ничего не знают, но это ж не значит что нигде не этот DAL нет ссылок

G>>Ты опять увиливаешь.
I>Тебе вероятно непонятно как можно жить без ссылок на DAL внутри модели и BL
Мне-то как раз понятно. А вот в Rich так не получится.

G>>>>И покажи код, который эффективно, с точки зрения трудозатрат и скорости работы, релизует эти юзкейсы.

I>>>Эффективно для абстрактного приложения или для конкретного ?
G>>Да неважно, самая затратная операция у тебя всегда будет одна при таких юзкейсах. Это доставание из базы.
I>Конечно. При этом она не имеет никакого отношения к бизнес-задаче. Поэтому она вынесена во внешний функционал, т.е. в инфраструктура.
Он того что ты назвал вещь по-другому код у тебя правильнее не станет.

I>Так и пиши — BFS, и не надо лепить порожние Linq-выражения.

Мы тут о работе с persisted данными говорим. Остальное не интересует и к архитектуре имеет посредственное отношение.

I>>>Ты взахлёб рассказываешь про дизайне, но при этом даже не поинтересовался, зачем нужен этот метод IsConnected.

G>>Это сейчас меня не интересует. Меня интересует как писать код в данном случае.
I>Вообще то должно интересовать, если ты хочешь поместить этот метод в правильное место. А особенно важно, если ты хочешь добиться того, что бы и другие девелоперы помещали методы в правильных местах, а не где попало.
Ты вроде привел код с service locator, а говоришь какую-то чушь. Важно чтобы девелоперы реализовали правильный интрефейс и положили классы в контейнер. Второе вообще говоря может делаться автоматически.

I>>>Если я скажу, что IsConnected используется как для валидации внутри модели(модель реактивная и умеет себя валидировать) так и для некоторых операций над моделью, ты сильно удивишься ?

G>>Абсолютно без разницы. См выше.

I>Это так кажется, что без разницы. В твоем случае внезапно может оказаться что надо в модель данных вводить депенденс от BL или вообще все методы выбрасывать в BL.

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

I>Имеем следующее — метод IsConnected

I>1 зависит исключительн от внутренностей Graph 2 зависит исключительно от сущностей которые не существуют вне Graph, т.е. graph управляет временем жизни этих объхектов
I>Следовательно, это равносильно тому, что IsConnected зависит исключительно от Graph.
I>Итого у класса Graph будет метод IsConnected который будет выполнять BFS над коллекциями узлов и ребер.
I>Что бы поднять IsConnected на уровень выше, в BL, нужно иметь существенные основания.
I>При том минимуме что я показал, в этом нет необходимости.
I>Могу показать, какие будут изменение при введении новых требований, если хочешь.
Ну ты считаешь изначально что все методы должны быть в объектах, а я считаю наоборот.

Вот я привел код, попробуй поместить IsConnected класс Graph, если уверен что там ему и место, но чтобы не поломались другие юзкейсы.
Re[21]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.12.10 10:51
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>
I>>var algEngine = container.Resolve<IAlgorithmManager>();
I>>var loader = container.Resolve<ILoader>(connection); 

I>>var newModel = algEngine.Apply(loader, oldModel);
I>>


G>Вот прекрасно, а скрипт этот где находится?


На диске и редактируется пользователем

G>и приведи контракты IAlgorithmManager и ILoader.


IModel Apply(IAlgorithm alg, IModel model);

void Run(Context ctx);

I>>Тебе вероятно непонятно как можно жить без ссылок на DAL внутри модели и BL

G>Мне-то как раз понятно. А вот в Rich так не получится.

Это так кажется.

I>>Конечно. При этом она не имеет никакого отношения к бизнес-задаче. Поэтому она вынесена во внешний функционал, т.е. в инфраструктура.

G>Он того что ты назвал вещь по-другому код у тебя правильнее не станет.

Опять пурга какая то. Объясняю по русски — в модели и BL нет ссылок на DAL.

I>>Так и пиши — BFS, и не надо лепить порожние Linq-выражения.

G>Мы тут о работе с persisted данными говорим. Остальное не интересует и к архитектуре имеет посредственное отношение.

Наоборот, имеет непосредтсвенное отношение и я уже объяснил почему.

G>Ты вроде привел код с service locator, а говоришь какую-то чушь. Важно чтобы девелоперы реализовали правильный интрефейс и положили классы в контейнер. Второе вообще говоря может делаться автоматически.


Придется решить ту же задачу — надо знать где искать какой метод, вводить новый интерфейс или не вводить.

I>>Это так кажется, что без разницы. В твоем случае внезапно может оказаться что надо в модель данных вводить депенденс от BL или вообще все методы выбрасывать в BL.

G>Ни разу такого не видел и даже причин не могу придумать от чего такая зависимость может получиться.

А было написано русским по зелёному

I>>При том минимуме что я показал, в этом нет необходимости.

I>>Могу показать, какие будут изменение при введении новых требований, если хочешь.
G>Ну ты считаешь изначально что все методы должны быть в объектах, а я считаю наоборот.

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

Судя по всему ты или не способен прочесть или просто валяешь дурака.

G>Вот я привел код, попробуй поместить IsConnected класс Graph, если уверен что там ему и место, но чтобы не поломались другие юзкейсы.


Какие "другие юзкейсы" ? На чем основана твоя уверенность, на книжках модных ?

Ты даже объяснить не можешь, чем руководствоваться для размещения метода в нужном месте.
Re[22]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.12.10 12:33
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>
I>>>var algEngine = container.Resolve<IAlgorithmManager>();
I>>>var loader = container.Resolve<ILoader>(connection); 

I>>>var newModel = algEngine.Apply(loader, oldModel);
I>>>


G>>Вот прекрасно, а скрипт этот где находится?


I>На диске и редактируется пользователем

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


G>>и приведи контракты IAlgorithmManager и ILoader.

I>IModel Apply(IAlgorithm alg, IModel model);
I>void Run(Context ctx);
Это к чему относится?

I>>>Тебе вероятно непонятно как можно жить без ссылок на DAL внутри модели и BL

G>>Мне-то как раз понятно. А вот в Rich так не получится.
I>Это так кажется.
Это так и есть

I>>>Конечно. При этом она не имеет никакого отношения к бизнес-задаче. Поэтому она вынесена во внешний функционал, т.е. в инфраструктура.

G>>Он того что ты назвал вещь по-другому код у тебя правильнее не станет.
I>Опять пурга какая то. Объясняю по русски — в модели и BL нет ссылок на DAL.
А ты не словами объясняй, а покажи на примере, я тебе привел пример для anemic, покажи как он же будет в rich.
А ты показал какие-то отдельные компоненты, а сама архитектура (взаимодействие компонент) отдано пользователю.

I>>>Так и пиши — BFS, и не надо лепить порожние Linq-выражения.

G>>Мы тут о работе с persisted данными говорим. Остальное не интересует и к архитектуре имеет посредственное отношение.
I>Наоборот, имеет непосредтсвенное отношение и я уже объяснил почему.
Не объяснил, ты пытался уйти от темы.


I>>>При том минимуме что я показал, в этом нет необходимости.

I>>>Могу показать, какие будут изменение при введении новых требований, если хочешь.
G>>Ну ты считаешь изначально что все методы должны быть в объектах, а я считаю наоборот.
I>Вообще то я привел свои рассуждения на счет того, почему конкретный метод должен оказаться именно у Graph.
Еще раз. Твои рассуждения опираются на то что ты считаешь что методы должны быть в классах с данными, есть и другая точка зрения.


G>>Вот я привел код, попробуй поместить IsConnected класс Graph, если уверен что там ему и место, но чтобы не поломались другие юзкейсы.

I>Какие "другие юзкейсы" ?
Не включай дурачка, я писал три юзкейса:

1)Список всех узлов.
2)Список всех линий.
3)Метод IsConnected.

И привел тебе еще пример кода, который показываем взаимодействие частей программы.

I>На чем основана твоя уверенность, на книжках модных ?

В книжках пишут про DDD и другие модные акронимы.

I>Ты даже объяснить не можешь, чем руководствоваться для размещения метода в нужном месте.

Ты не читаешь чтоли?
Я уже писал: функции могут группироваться по
1)Входным данным (это в точности методы класса)
2)Выходным данным
3)По решаемым задачам

Я предпочитаю группировать по 3), иногда по 1) и 2), причем все методы в отдельных "сервисах", те классах без состояния и identity.
Re[23]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.12.10 13:07
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>На диске и редактируется пользователем

G>На этом месте разговор можно закончить вообще говоря.
G>Архитектуры у программы нет, если взаимодействие компонент отдано пользователю.

Цитирую: "А параметры ему передает например cкрипт или код примерно такого вида: "

У тебя какие то проблемы со словом "например" ?

У тебя какие то проблемы с приведеным кодом ? Вроде всего три строчки было

Взаимодействие компонент может описываться скриптом. Но это не значит что пользователь обязан этим заниматься. Loader вполне может быть вызван из скрипта и пользователь может передать туда параметры.

G>>>и приведи контракты IAlgorithmManager и ILoader.

I>>IModel Apply(IAlgorithm alg, IModel model);
I>>void Run(Context ctx);
G>Это к чему относится?

Угадай с трех раз что называется. Первая строка — менеджер алгоритмов, вторая — алгоритм. ILoader — всего лишь специальное имя интерфейса.

I>>Опять пурга какая то. Объясняю по русски — в модели и BL нет ссылок на DAL.

G>А ты не словами объясняй, а покажи на примере, я тебе привел пример для anemic, покажи как он же будет в rich.

Честно говоря я не сильно понимаю, что такое rich а что такое anemic. Где ты хочешь увидеть ссылку на DAL ?

G>А ты показал какие-то отдельные компоненты, а сама архитектура (взаимодействие компонент) отдано пользователю.


Вообще то ты плохо читал.

G>>>Ну ты считаешь изначально что все методы должны быть в объектах, а я считаю наоборот.

I>>Вообще то я привел свои рассуждения на счет того, почему конкретный метод должен оказаться именно у Graph.
G>Еще раз. Твои рассуждения опираются на то что ты считаешь что методы должны быть в классах с данными, есть и другая точка зрения.

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

"Имеем следующее — метод IsConnected

1 зависит исключительн от внутренностей Graph 2 зависит исключительно от сущностей которые не существуют вне Graph, т.е. graph управляет временем жизни этих объхектов

Следовательно, это равносильно тому, что IsConnected зависит исключительно от Graph.

Итого у класса Graph будет метод IsConnected который будет выполнять BFS над коллекциями узлов и ребер."


I>>Какие "другие юзкейсы" ?

G>

G>1)Список всех узлов.
G>2)Список всех линий.
G>3)Метод IsConnected.


Из твоего кода выбросить GraphService и перенести метод IsConnected в Graph. Это что, так сложно ?

G>И привел тебе еще пример кода, который показываем взаимодействие частей программы.


Ты эти части сам же искусственно и ввел.

G>Я уже писал: функции могут группироваться по

G>1)Входным данным (это в точности методы класса)
G>2)Выходным данным
G>3)По решаемым задачам

Это общие слова.
Re[24]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.12.10 13:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>На диске и редактируется пользователем

G>>На этом месте разговор можно закончить вообще говоря.
G>>Архитектуры у программы нет, если взаимодействие компонент отдано пользователю.

I>Цитирую: "А параметры ему передает например cкрипт или код примерно такого вида: "


I>У тебя какие то проблемы со словом "например" ?


I>У тебя какие то проблемы с приведеным кодом ? Вроде всего три строчки было


I>Взаимодействие компонент может описываться скриптом. Но это не значит что пользователь обязан этим заниматься. Loader вполне может быть вызван из скрипта и пользователь может передать туда параметры.


G>>>>и приведи контракты IAlgorithmManager и ILoader.

I>>>IModel Apply(IAlgorithm alg, IModel model);
I>>>void Run(Context ctx);
G>>Это к чему относится?

I>Угадай с трех раз что называется. Первая строка — менеджер алгоритмов, вторая — алгоритм. ILoader — всего лишь специальное имя интерфейса.

Точно?
Твой код

var algEngine = container.Resolve<IAlgorithmManager>();
var loader = container.Resolve<ILoader>(connection); 

var newModel = algEngine.Apply(loader, oldModel);


Мой внутренний компилятор подсказывает что из-за выделенного проверку типов не пройдет.

Ну тем не менее давай углубляться, как устроен Run и что есть IModel?

I>>>Опять пурга какая то. Объясняю по русски — в модели и BL нет ссылок на DAL.

G>>А ты не словами объясняй, а покажи на примере, я тебе привел пример для anemic, покажи как он же будет в rich.

I>Честно говоря я не сильно понимаю, что такое rich а что такое anemic.

Однако... почитай темы с более чем 200 постами в этом форуме.


G>>А ты показал какие-то отдельные компоненты, а сама архитектура (взаимодействие компонент) отдано пользователю.

I>Вообще то ты плохо читал.
Да ты че? ты привел 3 строчки кода непонятного происхождения и еще объявил что за них пользователь отвечает. Я вообще не пойму какой код ты пишешь, а ты вечно уходишь от темы.


I>"Имеем следующее — метод IsConnected

I>1 зависит исключительн от внутренностей Graph 2 зависит исключительно от сущностей которые не существуют вне Graph, т.е. graph управляет временем жизни этих объхектов
I>Следовательно, это равносильно тому, что IsConnected зависит исключительно от Graph. (1)
I>Итого у класса Graph будет метод IsConnected который будет выполнять BFS над коллекциями узлов и ребер." (2)
Если у тебя Graph — persisted сущность, то есть сохраняется в базе, то это уже неверно.

I>>>Какие "другие юзкейсы" ?

G>>

G>>1)Список всех узлов.
G>>2)Список всех линий.
G>>3)Метод IsConnected.


I>Из твоего кода выбросить GraphService и перенести метод IsConnected в Graph. Это что, так сложно ?

Данивопрос, покажи кож. Выполняться должны все 3 юзкейса.

G>>И привел тебе еще пример кода, который показываем взаимодействие частей программы.

I>Ты эти части сам же искусственно и ввел.
Какие именно?

G>>Я уже писал: функции могут группироваться по

G>>1)Входным данным (это в точности методы класса)
G>>2)Выходным данным
G>>3)По решаемым задачам
I>Это общие слова.
Если не понимаешь, то помочь я не могу.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.