Многопользовательская транзакционная система и ASP.NET MVC

Question

Таким образом, у меня есть задача создать сайт, который люди в Интернете могут использовать для взаимодействия с организациями .: Клиентское приложение Asp.NET MVC

Одним из требований является финансовая обработка и учет.

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

Частью сложности здесь являются сами данные:

1. Я запрашиваю x баз данных (по одной на каждого существующего клиента), чтобы получить некоторые из моих данных, хотя у моего приложения есть и собственное хранилище данных. Мне нужно запросить базы данных x, запустить хранимые процедуры в базах данных x, а также в собственное хранилище данных.

2. Я не вижу сильной поддержки таких вещей, как хранимые процедуры и, следовательно, транзакции, хотя, похоже, они присутствуют.

Может быть, я просто пытаюсь сделать свое приложение здесь гвоздем, потому что молоток MVC ооочень блестящий. Конечно, мне вполне комфортно с сырым ADO.NET, но мне нравится выразительное чувство написания кода Linq на C #, и я бы предпочел не сдаваться.

До вопроса:

Это плохая идея? Должен ли я попытаться использовать Linq / Entity Framework или что-то вроде nHibernate ... и придерживаться шаблона ORM, или я должен удалить его и использовать доступ к данным ADO.NET?

Редактировать: примечание по шкале; с точки зрения количества запросов в секунду это приложение не является «огромным». Но, с точки зрения сложности данных, необходимо выполнить запрос к более чем 50 базам данных (все они идентичны или близки к нему), чтобы прочитать данные из внешнего приложения и опубликовать данные обратно в это приложение. ORM чувствует себя хорошо, когда имеешь дело с «моим» хранилищем данных, но чувствует себя очень неправильно для доступа к данным из внешнего приложения.

Answer 1

использование TransactionScope объект доступен в System.Transaction.

Answer 2

Начиная с определенного размера (количества баз данных), вы должны изменить парадигму. Вы в таком размере?

Когда вы развертываете то, что в конечном итоге является распределенным приложением, и при этом пытаетесь управлять им как обычным локальным приложением, вы столкнетесь с рядом фундаментальных проблем, связанных с доступностью, масштабируемостью и корректностью. Если вы используете такие понятия, как «распределенные транзакции», «связанные серверы» и «ORM», вы идете по неверному пути. Истинно распределенные приложения будут использовать такие термины, как «сообщение», «очередь» и «служба». Такие термины, как Linq, EF, nHibernate, хороши и хороши, но none принесет вам что-то дополнительно от того, что приносит простое выражение Transact-SQL SELECT. Другими словами, если SELECT решит ваши проблемы, то на стороне клиента будут работать различные ORM. В противном случае они не добавят никакой ценности miraculos.

Я рекомендую вам просмотреть слайды SQLCAT: высокопроизводительные распределенные приложения в развертываниях в реальном мире , которые объясняют, как сайту, подобному MySpace, удается читать и записывать в хранилище почти 500 серверов и тысячи серверов. базы данных.

В конечном итоге вам необходимо усвоить следующее: одна база данных может иметь доступность 95% (время работы и приемлемое время ответа службы). Система, состоящая из 10 баз данных с 95% доступностью, имеет 59% доступности. А система из 100 баз данных каждая с доступностью 99,5% имеет доступность 60%. 1000 баз данных с доступностью 99,95% (5 минут простоя в неделю) имеют доступность 60%. И это для идеальной ситуации. В действительности всегда есть эффект снежного кома, вызванный потреблением ресурсов (например, потоками, заблокированными при попытке получить доступ к недоступному или медленному ресурсу), который делает вещи намного хуже.

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

Answer 3

Я выбрал использование Entity Framework для предоставления доступа к основному хранилищу данных приложения и создания настраиваемого DAL для доступа к внешним данным приложения и для доступа к хранимым процедурам в приложении.

Здесь надеется, что Entity Framework 4.0 решит проблему. Сейчас я использую концепцию, перечисленную здесь.

http://social.msdn.microsoft.com/forums/en-US/adodotnetentityframework/thread/44a0a7c2-7c1b-43bc-98e0-4d072b94b2ab/