PavluxaF,

Есть много вариаций, но в основном, люди делятся на два лагеря и два подхода, Transaction Script и Domain Model. Подробное описание достоинств и недостатков каждого подхода можно найти в книжке "Мартина Фаулера - Архитектура корпоративных программных приложений".

Если вкратце то:
Transaction Script - процедурный подход, при котором вся логика сосредоточена в процедурах (в БД или слое доступа к данным) - такой подход более естественен для субд, его проще реализовать и он более естественный для субд, основным минусом называется дублируемость когда.
Domain Model - объектный подход, логика реализуется в объектах предметной области - такой подход плохо ложится в концепцию реаляционных бд, по этому как правило требуется отдельный слой доступа который бы занимался трансляцией реляционных данных в объекты и наоборот (ORM - object relational mapping). Для джавы таким популярным механизмом является hibernate, а если вы пишете на си-шарпе, то в .net популярны в основном следующие orm:
- NHibernate (вроде как самый зрелый и "взрослый" орм для дот нета, сам не использовал подробнее не скажу)
- Entity Framework (орм от майкрософта, интересная весчь, сейчас активно развивается, много документации с примерами на сайте майкрософт и блоге адо.нет)
- Linq to SQL (легковесный орм, подходит для простых задач, говорят что многого не умеет - сам активно не использовал, насчет правда или нет не скажу)

Далее гугл вам в помощ, почитайте фаулера, можете еще до кучи про доменную модель почитать эрика эванса - предметноориентирвоанное проектирование) и выбирайте. Из личного опыта скажу что у нас используется transaction script + domain model, так называемый anemic domain model, при этом логика в хранимых процедурах на сервере и в слое доступа к данным, дублировать код иногда действительно приходится - но ничего смертельного в целом.

Модератор: Тема перенесена из форума "Microsoft SQL Server".

Petro123,

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

Petro123,

От клиента как раз почти не зависит, особенно в таких похожих по парадигме языках как c#, java, object pascal. Зависит от задачи и какое решение примет в связи с этим архитектор. Настоятельно рекомендую вам прочесть-таки фаулера (можно только введение, самые первые несколько глав, для общего развития), там многие вопросы, которые чувствуется у вас вертятся в голове - рассмотрены, когда где что применять, по каким критериям выбирать и т.д. Еще про недостатки и достоинства, а так же холивары на тему "что лучше", можете почитать погуглив по фразам: "Anemic Domain model", "Rich Domain Model". На РСДН-е много попадается обсуждений.
Вот сходу Anemic Domain Model vs Rich Domain Model
Вот еще статейка Старые песни о главном: роль ООП при работе с данными...
Вот немножко про Domain Driven Design от майкрософта Введение в проблемно-ориентированное проектирование
Изучайте, думаю вкупе с перечисленными книгами, материала вам хватит надолго и скорее всего поможет выяснить все вопросы! =)

Petro123,
Пардоньте, перепутал вас с автором темы.

alexeyvg,
Да, есть такое. Но у нас не совсем так, у нас вообще нет ОРМ, есть слой доступа к данным в виде служб, есть объекты, которые являются по сути просто контейнерами для данных. Службы и клиент общаются при помощи этих объектов, сами объекты поведения не несут. Логика в основном в БД в ХП. Система распределенная, так что службы реализованы ввиде xml web services. Такая вот архитектурка. Мое предположение ответа на вопрос Petro123 "зачем так сделали" такое что: 1) распределенная архитектура а веб-сервисы легко пролазят через инет и прочие каналы 2) тогда, году в 2004 веб-сервисы были "в тренде" и МС активно их пиарила =) - но почему точно, я конечно не знаю.

Petro123== зависит. Я бы посмотрел, как вы в Delphi ORM будете мастрячить.
А вы наберите в поиске ORM Delphi и что-то там такое вылезет ведь, значит есть умельцы =) То, что никто не хочет писать серьезный ОРМ фреймворк для дельфи не значит что его нельзя сделать впринципе. Другое дело - кому это нужно? Ведь большинство проектов на дельфи уже лохматые-прелохматые, а новые сейчас большинство предпочитает начинать на майнстримовых платформах.
От клиента зависит только в том плане, что если используется другая парадигма, то против нее идти не стоит. Вот в sql нет объектов, попробуй тут в объектном стиле попиши, отнаследуй таблицу от таблицы =)

Petro123===== а также от библиотек, а также от ..... Скорее уж набор библитек зависит от того что выберет архитектор.

Petro123:)
там ЭТО не нужно, т.к. там MVC встроен в IDE.
Таблица.Данные = DAL (забиндили или привязались)
Эта парадигма появилась в Java-GWT от Гугла
Т.е. это ваши обёртки без состояния для веб-сервиса.
ЗЫ
В Net это DataSet
Если под MVC имеется ввиду Model View Controller, то вряд ли. Как раз все эти RAD среды ругали за то, что они пропагандировали кодирование в стиле "Smart UI". Когда логика пишется прямо в обработчиках события навешанных на контролы. А mvc - это когда вы взяли, к примеру, одно представление, отсоединили и поменяли его на другое, не тронув логику. Так что, для кодирования на дельфи в стиле mvc требуется предпринять кое-какие усилия (по крайней мере в том дельфи, точнее билдере, который я знал в 2005 году =). Я согласен с вами в том, что ОРМ для дельфи просто не нужен, но не потому что оно такое "дельфи", а потому что вроде как вышел язык из моды.

Кстати насчет "В Net это DataSet" - это тема активно у фаулера в книге муссируется, но, ИМХО, просто это было в те времена когда .нет только-только появлялся, не было linq, EF и прочих красивостей - сейчас бы, думается мне, он так не написал. Жаль что нет современных дополненных и исправленных изданий этой книги.

Petro123,

Ну так я и не говорю что нельзя, я в том сымсле чтоб без усилий. Кстати не совсем в тему, но так чисто поржать. Насколько быстро устаревает информация в ит сообществе.
Из той-самой книги фаулера.

Некисло он так википедию приложил!

iscrafm,

имеете ввиду что напишете:
buttonOnclick() { myfunction() }
и рядышком в этом же файле
myfunction() {...}
?

iscrafm,

И еще, попутно вопрос, если например вам надо в зависимости от той или иной логики - кнопку задизейблить, вы где это напишете?

iscrafmЕсть процедуры/функции бизнес-логики. Для связи их запуска с внешними событиями есть Акции. У контролов, к которым относится та же кнопка, если привязка на акцию. Т.е., когда вы разрабатываете логику, то вам фиолетово на то, кто ее вызовет, кнопка или еще какое-то событие, но логика всегда одна. Ну вот видите, акции (это ли не TAction - всплывают у меня смутные знания многолетней давности?)...уже появляется отдельная абстракция и механизм для реализации описанного поведения. Далее так или иначе придется связывать это с кнопками и прочим, опять же чтобы отвязать - нужно вводить какие-то интерфейсы и уровни абстракции - это и есть усилия.
iscrafmКонечно Делфи провоцирует щелкнуть мышкой на OnClick и настрочить там этот код, но это не более чем провокация, которая очень полезна для минутных приложений. А вот тут я пожалуй плюсану. Именно это ведь я и хотел сказать. Просто было утверждение Petro123там ЭТО не нужно, т.к. там MVC встроен в IDE. вроде как если встроен, то создаешь новый проект и сразу начинаешь мыслить в логике MVC, как например если создать проект в .нет ASP.NET MVC. Там как раз все встроено. По другому, конечно, и там можно написать, но это надо потратить усилия. В этом же случае усилия как раз надо приложить в том, чтобы разобраться, как не свернуть на путь "создал форму, накидал контролов, обработчиков, все написал и фигачишь себе дальше" - именно на это и провоцирует дизанер форм (как впрочем не только в дельфи, но и в вин-формсе в .нет).

iscrafmда ладно вам.. не путайте архитектуру приложения и язык программирования, при помощи которого оно реализуется. Нужен DAL отделенный от BLL - делайте так. Какая разница на каком языке писать текст для этого.
И тут я плюсану. Ибо то же самое писал еще ранее. Не зависит от клиента практически какой подход использовать, если это не противоречит парадигме и возможностям языка. Обжект паскаль объектный? объектный! Есть компоненты работы с БД? Есть! Что мешает нафигачить классический ОРМ если это нужно? Да ничего не мешает. Ровно это я и талдычу уже который пост. Нет в явном виде зависимости между ОРМ и языком программирования если он имеет все возможности для этого. Нельзя сказать: Ява - ОРМ, .НЕТ - ДатаСет, Дельфи - еще что-то. Это то, что я хотел сказать.

Petro123я думал, у нас бОльшие проблемы.
А у нас тут: "кнопку выключить" :))
Давай лучше offtop
Ну кагбэ дьявол кроется в мелочах, я привел реальный пример места в котором надо стыковать два подхода - MVC и Smart UI.

PavluxaF,

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

SomewhereSomehowНу кагбэ дьявол кроется в мелочах, я привел реальный пример места в котором надо стыковать два подхода - MVC и Smart UI. Не стыковать конечно, а выбирать между.
Устал я, спать пойду =)

iscrafmНикаких абстракций дополнительных не нужно. Для связывания тоже никаких доп.интерфейсов не нужно. Для биндинга в компонентах есть свойство Action. Ничуть не сомневаюсь, что при грамотном использовании Action можно писать в духе MVC. Но, по прежнему:
iscrafmКонечно Делфи провоцирует щелкнуть мышкой на OnClick и настрочить там этот код, но это не более чем провокация, которая очень полезна для минутных приложений.
так что как-то неубедительно для меня звучит фраза о встроенном MVC в дельфи и написании в таком стиле без усилий. На любом подобном языке можно писать в стиле MVC и во многих фреймворках есть компонентная модель. По такой же логике можно сказать, что MVC везде встроен. Только чтобы его использовать, надо сделать то-то и то-то, использовать такие-то компоненты и связывать с контролами определенным образом.

Petro123SomewhereSomehow,
- вы на MVC сильно не молитесь. Счас уже MVP в моде
http://en.wikipedia.org/wiki/Model-view-presenter
- В Delphi есть разделение архитектуры на уровни по вертикали.
Считай - компонентный фреймворк. Хотя можно и на API win32 и на ASM перейти.
Т.е.прикладник программист берёт DAL и присоединяет его к VIEW в виде DevExpress.
Контроллёр там внутри. Его пишет системщик создавая библиотеку-уровень.
В Java нету такого деления на прикладника. Поэтому каждый строит Модель, Маппит её на БД, замешивает всё на Хибер, пишет логику в классах, и пишет клиента на HTML-шаблонах или...
Подходы разные, и нет Лучшего или Худшего. MVC/MVP - не суть. Не понимаю, что мешает вам например в том же .NET сделать: "берёт DAL и присоединяет его к VIEW в виде DevExpress."? Сам по себе оо язык программирвоания ни к чему особо не обязывает. Так что я по прежнему недоумеваю, зачем вешать ярлыки (кроме, конечно, языков созданных для специальных нужд, типа sql - для работы с данными, фортран - для математических задач и т.д...).

iscrafmдался вам этот MVC. Делфи - среда разработки. А какой проектной модели придерживается архитектор системы - дело архитектора. Является он сторонником MVC - получите, хотите MVVM - пожалуйста и т.д. Мне нравится, что в него встроен MIE по умолчанию. Да мне то он не дался, я как раз и пытаюсь объяснить Petro123 что не надо вешать ярлыков. Это для того, это для сего и т.д. А вообще это все к тому, что ТС собственно и интересавался в теме где ему организовывать БЛ, хотя теперь тема уже больше перерастает в какой-то флуд.