Автоматическая генерация Даль в приложении ASP.NET

StackOverflow https://stackoverflow.com/questions/1639313

Вопрос

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

План состоит в том, чтобы архитектура имела:

ASP.NET код, лежащий в основе -> Бизнес-уровень -> Уровень доступа к данным -> Хранимая процедура.

Уровень BL действует как переход к DAL и также может быть сгенерирован автоматически.

Любые советы действительно ценятся!

Это было полезно?

Решение

Entity Framework в его текущей форме не является началом хранимых процедур. Просто нужно слишком много ручной работы, чтобы каждая хранимая процедура работала. Однако я не могу говорить за .net 4 Entity Framework.

LINQ to SQL очень удобен для работы с хранением. Запустите SQLMETAL с параметром / procs, чтобы он автоматически генерировал ваш DAL.

Однако есть два ограничения:

<Ол>
  • LINQ to SQL не будет запускать хранимые процессы, использующие динамический SQL.
  • LINQ to SQL также не будет запускать хранимые процедуры, которые возвращают данные из временных таблиц.

    • Очевидная первая причина заключается в том, что LINQ to SQL не может генерировать необходимые метаданные для этих sprocs, но динамический SQL в хранимых процессах в любом случае является плохой практикой.

    Другие советы

    Просто используйте Entity Framework:
    http://msdn.microsoft.com/en-us/library/bb399203. ASPX

    Я пока не предлагаю вам использовать Entity Framework, поскольку в нем все еще есть много особенностей. После официального выпуска .NET 4.0 у вас будет Entity Framework 4.0. В этом выпуске я, вероятно, откажусь от NHibernate и LINQ to SQL (у обоих очень разные роли) и просто использую EF, поскольку он имеет простоту использования LINQ to SQL и гибкость NH.

    А пока я предлагаю вам использовать LINQ to SQL, так как его очень легко запустить и запустить, и большую часть времени он просто работает!

    Linq2SQL или SubSonic хорошо работают для этой цели.

    Редактировать: Linq2Sql предположительно "мертв", но все еще весьма полезен в своем нынешнем виде. Я просто не буду вкладывать в это долгосрочные инвестиции.

    Еще один голос за платформу Entity, хотя это будет зависеть от базовой структуры таблицы, а не от хранимой процедуры. Я не знаю, как позволить Entity Framework определять структуру классов на основе сохраненных выходных данных процесса.

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

    Клише здесь по причине: если вы хотите, чтобы все было сделано правильно, сделайте это сами. Чем больше сторонних компонентов вы вводите в свое приложение, тем больше проблем, которые вы просите решить, не находятся под вашим непосредственным контролем. Я ненавижу подписываться на синдром «Не изобретено-здесь», но это один из случаев, когда я считаю, что он действителен.

    Ознакомьтесь с этим списком самых известных Инструменты ORM ".Net"

    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top