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,

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