В автономном приложении », где должна находиться бизнес-логика? - PullRequest
1 голос
/ 08 ноября 2010

Я прочитал книгу Тома Кайта "Эффективный Оракул по замыслу". Там он говорит написать большую часть кода в самой БД, чтобы уменьшить код приложения. Это хорошо в распределенной среде, но выгодно ли и в автономном приложении?

Мое приложение. находится в .NET.

Ответы [ 2 ]

6 голосов
/ 08 ноября 2010

Да, есть много преимуществ для размещения бизнес-логики в базе данных Oracle даже для отдельного приложения:

  • Производительность и масштабируемость, где бизнес-логика предполагает доступ к базе данных или ее обновление
  • Отслеживание зависимостей: ссылки на таблицы и другие объекты в вашем коде легко найти
  • PL / SQL предназначен для написания кода, который обращается к базе данных, очень просто и без необходимостидля создания множества динамически подготовленных операторов SQL или использования запутывающего слоя, такого как Hibernate, чтобы сделать это для вас.

Я бы на самом деле украл часть ответа Джоша и повернул бы его на 180 градусов:

ЕСЛИ ваша база данных будет когда-либо поддерживать только одно приложение, и ЕСЛИ вы никогда не ожидаете, что одни и те же данные будут иметь разные варианты использования в зависимости от того, кто их использует ... тогда обязательно включите бизнес-логику в ...

приложение.

Я имею в виду, вы серьезно хотите два разных приложенияs для доступа к одним и тем же строкам данных, но применять другие правила к изменениям этих данных?Какой смысл иметь «правило», если вы можете нарушить его, просто используя другой путь доступа?

Обратите внимание, что я пропустил эту часть ответа Джоша:

...Если вы никогда не планируете использовать другой механизм хранения ...

Конечно, , если , вы планируете поддерживать несколько баз данных или отказаться от Oracle и начать использоватьSQL Server или что-то еще для хранения ваших данных, тогда вы не захотите использовать PL / SQL для написания своего кода.Но во многих, многих случаях этого не произойдет, и вам не следовало бы добиваться независимости базы данных для себя.

2 голосов
/ 08 ноября 2010

ЕСЛИ ваша база данных будет поддерживать только одно приложение, а ЕСЛИ вы никогда не ожидаете, что одни и те же данные будут по-разному использоватьсяв зависимости от того, кто его использует, и IF вы никогда не планируете использовать другой механизм хранения ... тогда обязательно поместите бизнес-логику в базу данных.

Однако, если что-то из этого является правдой (как я подозреваю).Тогда я, и, вероятно, большинство людей на этом сайте, настоятельно рекомендую вам не идти по этому пути.

Помещение логики в БД может быть соблазнительным, поскольку вы думаете: «Я могу изменить это на лету!»но это дорога для техобслуживания, по которой вы не хотите идти.Слушайте голос опыта и держите свои проблемы отдельно.

Мое приложение.это отдельное приложение для WindowsЭто решение для инвентаризации и выставления счетов.В настоящее время я написал классы, содержащие методы для выполнения различных операций с БД, таких как вставка, обновление и удаление.Интересно, если бы я мог писать хранимые процедуры в самой БД и передавать параметры только через интерфейс .NET, какое это может дать преимущество?

Это на самом деле не похоже на бизнес-логику для менявообще, если конечно вы не делаете что-то большее, чем просто операции CRUD.В этом случае то, используете ли вы хранимые процедуры, ORM или сгенерированные вручную запросы в коде, является подробностью реализации.

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

public class MyDomainObject
{
    public String Name {get; set;}

    public Boolean IsValid()
    {
        return !String.IsNullOrWhitespace(Name) &&
           DoesNotContainInvalidCharacters(Name);
    }
}

public class MyDataAccess
{
    public List<MyDomainObject> GetAll()
    {
        //Some data access logic here
    }

    public MyDomainObject GetByName(String name)
    {
        //Some data access logic here
    }

    public void Save(MyDomainObject)
    {
        if(MyDomainObject.IsValid)
        {
            //Some data access logic here
        }
    }
}

Итак, теперь у вас есть объект домена и объект доступа к данным .Объект домена применяет некоторую тривиальную бизнес-логику, которую можно проверить с помощью свойства IsValid, и уровень доступа к данным использует его, чтобы определить, следует ли сохранить его или нет.Однако подробности о том, как хранятся данные, не имеют большого значения для уровня домена / бизнеса.

Если вы хотите провести рефакторинг для использования хранимых процедур, ваше приложение на самом деле не должно волноваться.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...