.net 4 Архитектура: MVC, службы данных WCF, шаблон репозитория, Entity Framework объединяются?

Question

У меня есть роскошь начинать с нуля со всеми последними новинками .net 4 bit & bobs. Мое приложение должно поддерживать различные клиенты, включая веб-сайт MVC, приложение для iphone, приложение andriod и другие веб-сайты

Мое приложение обрабатывает довольно много пространственных данных и должно будет полагаться на кеширование, поскольку оно предоставляет гео-RSS-каналы, позволяющие отображать области в виде полигонов на Bing Maps Ajax 7.

Я знаю, что хочу использовать все вышеперечисленные технологии, НО я еще не уверен на 100%, как они все собираются вместе.

К сожалению, E.F. 4 не поддерживает пространственные типы данных ИЛИ аннулирование кэша SqlDependecy. В связи с этим, для части доступа к данным я решил воспользоваться SqlCommands / хранимыми процедурами ADO .net 2 (я также думаю, что будет целесообразно предварительно скомпилировать функции SQL Spatial и выполнять их внутри SQL Server).

Отсюда из моего нынешнего понимания вот что я думаю:

1) У меня будет .edmx, который делает доступ к данным для типов без пространственных свойств. Затем у меня будут репозитории для тех типов, которые используют объекты .edmx и возвращают объекты POCO (используя шаблоны POCO EF4).

2) У меня будут репозитории с рукописным кодом ADO .net 2 для типов с пространственными битами.

3) У меня будут классы Service Layer (написаны от руки), которые инкапсулируют репозитории (не знаю, как они реализованы или с чем они разговаривают). Здесь я реализую безопасность и бизнес-логику.

4) У меня будет служба данных WCF (.net 4), развернутая в отдельном приложении, которое отображает уровень обслуживания как OData для различных клиентов.

5) Мой MVC as будет общаться с моим уровнем службы данных WCF из кода контроллера.

6) Другие клиенты будут общаться с уровнем службы данных WCF и работать с OData так, как они хотят.

Это имеет смысл? Использование OData для вызова бизнес-операций вместо CRUD? Существуют ли основные препятствия и проблемы с безопасностью и идентичностью над Одатой?

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

Answer 1

Жесткая любовь здесь.

Не используйте BFUD (большой дизайн), если вы не понимаете, с какими технологиями вы хотите работать.Вы принесете больше вреда, чем пользы.Используя самые популярные шаблоны! = Успех.

Начните с малого, добавьте крошечные кусочки и вырастите оттуда.

Answer 2

Согласитесь с тем, что в архитектуре вашей системы звучит довольно много неизвестных - сохраняйте это как можно проще - наличие двух отдельных DAL (ODATA и вашего пользовательского) - это адский рецепт поддержки кода. -вы можете пропустить часть одата.

ваши части 2 и 3, 6 кажутся немного сомнительными, если вашим клиентам необходим доступ к пространственным типам данных одновременно с данными REST службы ODATA. не знаю, как вы можете решить, что

Я скажу, что к ODATA можно очень легко получить доступ из клиентских приложений .NET, и есть поддержка клиентского доступа через Javascript, Java (см. RESTLET) - это здорово, учитывая мой ограниченный опыт работы с ним для сервиса .NET и .NET клиенты - еще не использовали его на клиентах не .NET

Удачи .. Я хотел бы знать, как все это получается.