Учитывая хранимую процедуру, есть ли способ автоматически сгенерировать уровень доступа к данным? Я понимаю, что это можно сделать с помощью Codesmith, создав шаблоны cs, но мне было интересно, есть ли там бесплатное/платное решение.
План состоит в том, чтобы архитектура имела:
Код ASP.NET позади -> Бизнес-уровень -> Уровень доступа к данным -> Хранимая процедура.
Слой BL действует как переход к DAL и также может генерироваться автоматически.
Любые советы/советы действительно ценятся!
Entity Framework в его нынешнем виде не подходит для хранимых процедур. Слишком много ручной работы нужно сделать, чтобы каждая хранимая процедура заработала. Однако я не могу говорить за .net 4 Entity Framework.
LINQ to SQL очень удобен для хранимых процессов. Запустите SQLMETAL с параметром /procs, чтобы он автоматически сгенерировал ваш DAL.
Однако два ограничения:
Очевидная первая причина заключается в том, что LINQ to SQL не может генерировать необходимые метаданные для этих процедур, но динамический 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, который ограничен, особенно с учетом возможностей использования хранимых процедур, которые будет блокировать фреймворк.
Клише существуют не просто так: если хочешь, чтобы все было сделано правильно, сделай это сам. Чем больше сторонних компонентов вы вводите в свое приложение, тем больше проблем вы просите решить, которые не находятся под вашим непосредственным контролем. Я ненавижу подписываться на синдром Not-Invented-Here, но это тот случай, когда я считаю, что это действительно так.
Посмотрите этот список самых известных инструментов ORM ".Net"
