Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Чушь. Я вот как ни кручу, у меня не получается ссылки на dal как ты расписывал
G>>Show Me The Code. Я тебе покажу ссылку.
I>Обычная модель графа — граф, узлы, ребра.
Меня как всегда интересуют методы, а тебя "предметная область".
Так покажи каким сущностям предметной области соответствует твой граф, и скажи что за метод в любой сущности использует связанные.
Re[13]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, gandjustas, Вы писали:
I>>Обычная модель графа — граф, узлы, ребра.
G>Меня как всегда интересуют методы, а тебя "предметная область".
G>Так покажи каким сущностям предметной области соответствует твой граф, и скажи что за метод в любой сущности использует связанные.
граф — сеть. узел — узел. ребро — линия связи.
Твоя формула "Есть класс A, который содержит некоторые данные описывающие предметную область, и метод B, реализующий некоторую функцию.
Функция в свою очередь обращается к другим данным (когда не обращается — нам неинтересно). То есть в A должна быть ссылка на DAL, tesability идет лесом и получается каша.
"
А = граф. Б — метод графа, например IsConnected, возвращает связный ли граф. Другие данные — вершины и ребра.
Итого — никаких ссылок на DAL не нужна.
Re[14]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Обычная модель графа — граф, узлы, ребра.
G>>Меня как всегда интересуют методы, а тебя "предметная область".
G>>Так покажи каким сущностям предметной области соответствует твой граф, и скажи что за метод в любой сущности использует связанные.
I>граф — сеть. узел — узел. ребро — линия связи.
I>Твоя формула "Есть класс A, который содержит некоторые данные описывающие предметную область, и метод B, реализующий некоторую функцию. I>Функция в свою очередь обращается к другим данным (когда не обращается — нам неинтересно). То есть в A должна быть ссылка на DAL, tesability идет лесом и получается каша. I>"
I>А = граф. Б — метод графа, например IsConnected, возвращает связный ли граф. Другие данные — вершины и ребра.
I>Итого — никаких ссылок на DAL не нужна.
Ты грузишь весь граф из хранилища в память?
Ну для начала. Думаю у графа есть значительно больше методов, чем IsConnected. Например возьмем простые и насущные: отображение
1)Список всех узлов.
2)Список всех линий.
Как они в такой модели решаться будут?
Ну покажи код, я прям потыкаю.
Re[3]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Sinix, Вы писали:
S>Сваливание логики и данных в одну кучу приводит к прогибанию структуры данных под текущие требования. Поддерживать получившееся месиво — занятие крайне неблагодарное.
Нет никакого сваливания в кучу
S>2. Данные должны быть отделены от бизнес-логики.
Это и ежу понятно. Речь о том, что Domain model это модель данных + бизнес-логика.
Re[15]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, gandjustas, Вы писали:
I>>Итого — никаких ссылок на DAL не нужна.
G>Ты грузишь весь граф из хранилища в память?
Могу грузить, могу не грузить. В модели, сервисах нет никаких ссылок на DAL.
G>Ну для начала. Думаю у графа есть значительно больше методов, чем IsConnected. Например возьмем простые и насущные: отображение G>1)Список всех узлов. G>2)Список всех линий.
G>Как они в такой модели решаться будут?
Очень просто, путём итерации по коллекции.
G>Ну покажи код, я прям потыкаю.
Ты отказался не то что код показать, а даже мало мальски пояснить свою идею.
Все что я сейчас делаю — заставляю тебя пояснять твою же идею
Re[16]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, 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]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, 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>
Ты показал вcе что угодно, кроме IsConnected. Где проверка достижимости узлов ?
G>Ты утверждаешь что можешь внести IsGraphConnected внутрь метода Graph без уменьшения эффективности программы и увеличения писанины. G>Покажи как это сделать.
Для начала давай определимся, пример для абстрактного приложения или для конкретного ?
Абстрактный случай я оставлю тебе, ты по ним большой специалист.
Ты взахлёб рассказываешь про дизайне, но при этом даже не поинтересовался, зачем нужен этот метод IsConnected.
Если я скажу, что IsConnected используется как для валидации внутри модели(модель реактивная и умеет себя валидировать) так и для некоторых операций над моделью, ты сильно удивишься ?
Re[2]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Аноним, Вы писали:
А>Имхо неправильно, т.к. сущности ничего не должны знать о бизнес логике, т.к. поведение все же должно быть локализовано в слое бизнес логики. С другой стороны часто нужен механизм реагирования на изменения состояния сущностей (скорее всего не всех, а каких-то конкретных). Этот механизм легко реализуется используя шаблон обратной зависимости.
Бизнес-логика понятие сильно растяжимое
Re[18]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, 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>>
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]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, 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]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Аноним, Вы писали:
А>>>Имхо неправильно, т.к. сущности ничего не должны знать о бизнес логике, т.к. поведение все же должно быть локализовано в слое бизнес логики. С другой стороны часто нужен механизм реагирования на изменения состояния сущностей (скорее всего не всех, а каких-то конкретных). Этот механизм легко реализуется используя шаблон обратной зависимости.
I>>Бизнес-логика понятие сильно растяжимое
А>Конечно, но системы надо структурировать единообразно.
Единообразно это касается подхода или же дизайна ?
Если подхода — "выявить важнейшие требования и на этом основании предложить конкретную структуру", то я согласен.
А если единообразно это "у разных моделей должна быть одинаковая структура" то это к доктору.
Вот gangjustas все хочет убедить меня, что модель данных или BL просто обязаны иметь ссылку на DAL
Re[5]: Обращение к бизнеслогике приложения из сущности.
От:
Аноним
Дата:
24.12.10 14:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Единообразно это касается подхода или же дизайна ?
И того и другого, но конечно по мере сил
I>А если единообразно это "у разных моделей должна быть одинаковая структура" то это к доктору.
Я бы сказал — узнаваемая и привычная структура
I>Вот gangjustas все хочет убедить меня, что модель данных или BL просто обязаны иметь ссылку на DAL
Думаю вы о разных вещах говорите, в роли DAL например WCF может быть использован...
Re[6]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Ikemefula, Вы писали:
I>>Единообразно это касается подхода или же дизайна ?
А>И того и другого, но конечно по мере сил
I>>А если единообразно это "у разных моделей должна быть одинаковая структура" то это к доктору.
А> Я бы сказал — узнаваемая и привычная структура
I>>Вот gangjustas все хочет убедить меня, что модель данных или BL просто обязаны иметь ссылку на DAL
А>Думаю вы о разных вещах говорите, в роли DAL например WCF может быть использован...
Конечно может. Но это не значит что в модели и BL будет ссылка на этот DAL
Re[20]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Ikemefula, Вы писали:
I>>>Создается в рантайме некоторым алгоритмом. Этим алгоритмом может быть как известный тебе cost based mesh design , так и import, load и тд. G>>Алгоритм откуда данные берет? Тоже из воздуха?
I>Алгоритм берет данные из своих параметров А параметры ему передает например cкрипт или код примерно такого вида:
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]: Обращение к бизнеслогике приложения из сущности.
На диске и редактируется пользователем
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]: Обращение к бизнеслогике приложения из сущности.
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]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, 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]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, 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>Это общие слова.
Если не понимаешь, то помочь я не могу.