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

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

G>

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

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

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

Маркерный интерфейс тебя смутил ?

interface ILoader : IAlogrithm {}

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

Run это и есть твой алгоритм. Как напишешь его, так он и будет устроен IModel это интерфейс рутового объекта модели. Он нужен для того, что бы разделить инфраструкту и модель. Ты ж понимаешь, что тащить Graph в другое приложение нет никакого резона.

I>>Честно говоря я не сильно понимаю, что такое rich а что такое anemic.
G>Однако... почитай темы с более чем 200 постами в этом форуме.

Так читал неоднократно Сторонники анемик и рич дошли до того, что у анемистов появились методы в прямо в модели, а у рич нарисовался слой сервисов

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

Ответ был даден предельно ясно — "например скрипт" или "код примерно такого вида...".

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

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

А что такое persisted сущность в твоем понимании ? Хочу уточнить, а то мне совсем неохота открывать очередной источник буззвордов, общих фраз и порожнего кода

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

Смотри внимательно:

public class Graph : Base
{
    public ICollection<Vertex> Verticies { get; set; }
    public ICollection<Edge> Edges { get; set; }
    /// 
    public bool IsConnected();
    //...
}

public class Vertex  : Base
{
    public ICollection<Edge> Edges { get; set; }
}

public class Edge : Base
{
    public Vertex A { get; set; }
    public Vertex Z { get; set; }
    //...
    public GetAnotherEnd(Vertex v);
}

public class Base
{
    public int Id {get;set;}
    public Base Parent{get;set;}
}

Хватит столько или еще чего добавить ?

G>>>И привел тебе еще пример кода, который показываем взаимодействие частей программы.
I>>Ты эти части сам же искусственно и ввел.
G>Какие именно?

я имею ввиду выделение GraphService.

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

Чего я понимаю, что ты читаешь и что ты пишешь это ажно ТРИ большие разницы

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

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

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

G>>

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

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

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

I>Маркерный интерфейс тебя смутил ?

interface ILoader : IAlogrithm {}

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


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

I>Run это и есть твой алгоритм. Как напишешь его, так он и будет устроен IModel это интерфейс рутового объекта модели. Он нужен для того, что бы разделить инфраструкту и модель. Ты ж понимаешь, что тащить Graph в другое приложение нет никакого резона.
Давай подробнее, какие методы в IModel, и как в коде появляется oldModel

I>>>Честно говоря я не сильно понимаю, что такое rich а что такое anemic.
G>>Однако... почитай темы с более чем 200 постами в этом форуме.

I>Так читал неоднократно Сторонники анемик и рич дошли до того, что у анемистов появились методы в прямо в модели, а у рич нарисовался слой сервисов
На выделенное приведешь ссылку?

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

I>Ответ был даден предельно ясно — "например скрипт" или "код примерно такого вида...".
I>У тебя возникли какие то проблемы с этим ?
Ответ то ясен, а кода нет. Можно считать сознательным уходом от темы и прекратить разговор.

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

I>А что такое persisted сущность в твоем понимании ? Хочу уточнить, а то мне совсем неохота открывать очередной источник буззвордов, общих фраз и порожнего кода
См выделенное выше. Ты походу вообще не читаешь.

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

I>Смотри внимательно:
I>

I>public class Graph : Base
I>{
I>    public ICollection<Vertex> Verticies { get; set; }
I>    public ICollection<Edge> Edges { get; set; }
I>    /// 
I>    public bool IsConnected();
I>    //...
I>}

I>public class Vertex  : Base
I>{
I>    public ICollection<Edge> Edges { get; set; }
I>}

I>public class Edge : Base
I>{
I>    public Vertex A { get; set; }
I>    public Vertex Z { get; set; }
I>    //...
I>    public GetAnotherEnd(Vertex v);
I>}

I>public class Base
I>{
I>    public int Id {get;set;}
I>    public Base Parent{get;set;}
I>}
I>

I>Хватит столько или еще чего добавить ?
Конечно добавить, методы поулчения списка вершин и дуг, причем не для одного графа, а всех.
А теперь самый интересный вопрос. Очевидно IsConnected обращается к Verticies и Edges, но если это не LL коллекции, то у тебя может падать IsConneted если не загружены связанные сущности. То есть ты не сможешь обеспечить независимость от DAL, то у тебя будет или LL — ссылка на DAL, или неявная связь с DAL, которая тебя явно грузить связанные сущности до вызова IsConnected.
Как будешь бороть?


G>>>>И привел тебе еще пример кода, который показываем взаимодействие частей программы.
I>>>Ты эти части сам же искусственно и ввел.
G>>Какие именно?
I>я имею ввиду выделение GraphService.
И че?

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

I>Чего я понимаю, что ты читаешь и что ты пишешь это ажно ТРИ большие разницы
Ну так если ты не читаешь или не понимаешь что я пишу, то это не мои проблемы.

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

I>>Маркерный интерфейс тебя смутил ?

interface ILoader : IAlogrithm {}

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

Очень удобно, решает многие вопросы конфигурации.

I>>Run это и есть твой алгоритм. Как напишешь его, так он и будет устроен IModel это интерфейс рутового объекта модели. Он нужен для того, что бы разделить инфраструкту и модель. Ты ж понимаешь, что тащить Graph в другое приложение нет никакого резона.
G>Давай подробнее, какие методы в IModel, и как в коде появляется oldModel

Ты уже видел этот код, с той разницей что вместо загрузки будет инициализация пустой модели, и в качестве oldModel будет null.

IModel

object Root {get;set}

I>>Так читал неоднократно Сторонники анемик и рич дошли до того, что у анемистов появились методы в прямо в модели, а у рич нарисовался слой сервисов
G>На выделенное приведешь ссылку?

Попроси, что бы прикрутили нормальный поиск к rsdn, найду.

I>>Ответ был даден предельно ясно — "например скрипт" или "код примерно такого вида...".
I>>У тебя возникли какие то проблемы с этим ?
G>Ответ то ясен, а кода нет. Можно считать сознательным уходом от темы и прекратить разговор.

Код вообще то был. Ты его не понял что ли ?

I>>А что такое persisted сущность в твоем понимании ? Хочу уточнить, а то мне совсем неохота открывать очередной источник буззвордов, общих фраз и порожнего кода
G>См выделенное выше. Ты походу вообще не читаешь.

Понятнее мне не стало, но если ты не хочешь пояснять — не надо.

G>Конечно добавить, методы поулчения списка вершин и дуг, причем не для одного графа, а всех.

Разуй глаза — все что надо есть.

Модель пишется под конкретное использование, а не под любое. Отсюда и разница в дизайне Потому не надо никаких дополнительных методов.

G>А теперь самый интересный вопрос. Очевидно IsConnected обращается к Verticies и Edges, но если это не LL коллекции, то у тебя может падать IsConneted если не загружены связанные сущности. То есть ты не сможешь обеспечить независимость от DAL, то у тебя будет или LL — ссылка на DAL, или неявная связь с DAL, которая тебя явно грузить связанные сущности до вызова IsConnected.
G>Как будешь бороть?

Сначала ты искал ссылку на DAL, щас вот уже ищешь неявную связь с DAL. Конечно же эта неявная связь есть и я даже говорил и не раз, где она — ни в модели, ни в BL, но в инфраструктуре и вызывающем коде

I>>Чего я понимаю, что ты читаешь и что ты пишешь это ажно ТРИ большие разницы
G>Ну так если ты не читаешь или не понимаешь что я пишу, то это не мои проблемы.

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

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

I>Разуй глаза — все что надо есть.
Покажи код.

I>Модель пишется под конкретное использование, а не под любое. Отсюда и разница в дизайне Потому не надо никаких дополнительных методов.
То есть модель таки зависит от функций, а не от "предметной области". Ты помницца пытался доказать обратное, или не ты?

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

I>>Разуй глаза — все что надо есть.
G>Покажи код.

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

I>>Модель пишется под конкретное использование, а не под любое. Отсюда и разница в дизайне Потому не надо никаких дополнительных методов.
G>То есть модель таки зависит от функций, а не от "предметной области".

Более подробно этот "парадокс" я уже объяснял. Хочешь, могу еще раз. В проектировании печатных плат нет и не будет сторнирующией проводки, а в складском учете нет и не может быть прозвона цепи.
Предметная область определяет и функции в то числе. При чем бОльшую часть функций можно назвать даже не знакомясь с детальным ТЗ. Более того, функции всега формулируются в терминах предметной области.

>Ты помницца пытался доказать обратное, или не ты?

Похоже у тебя хронические проблемы с чтением.