Структура проекта .NET Entity Framework (архитектура)

Question

Я пытаюсь определить, как лучше всего спроектировать проект .NET Entity Framework, чтобы получить хороший многоуровневый подход. До сих пор я пробовал это в основанной на просмотре игре, где игроки владеют и управляют планетами. Вот как у меня это получается:

Веб-сайт

Содержит весь интерфейс.

C # Project - MLS.Game.Data

Содержит файл EDMX со всеми моими сопоставлениями данных. Не так много здесь.

C # Project - MLS.Game.Business

Это содержит различные классы, которые я называю «Менеджеры», такие как PlanetManager.cs. Менеджер планет имеет различные статические методы, которые используются для взаимодействия с планетой, например getPlanet (int planetID) , который возвращает объект сгенерированного кода из MLS.Game.Data.

С сайта я сделаю что-то вроде этого:

var planet = PlanetManager.getPlanet(1);

Возвращает объект Planet из MLS.Game.Data (сгенерированный из EDMX). Это работает, но это до некоторой степени беспокоит меня, потому что это означает, что мой интерфейс должен ссылаться на MLS.Game.Data. Я всегда чувствовал, что графический интерфейс должен только ссылаться на бизнес-проект.

Кроме того, я обнаружил, что мои классы менеджера имеют тенденцию становиться очень тяжелыми. Я закончу с десятками статических методов в них.

Итак ... мой вопрос - как все остальные выкладывают свои проекты ASP EF?

EDIT

Еще через некоторое время есть дополнительные предметы, которые меня беспокоят. Например, допустим, у меня есть объект Planet, который снова генерирует код из мастера. Что если придет время, когда моей Планете понадобится специальное свойство, скажем «Население», которое является своего рода вычислением, основанным на других свойствах объекта Планета. Хотел бы я создать новый класс, унаследованный от Planet, а затем вернуть его? (хм, интересно, запечатаны ли эти классы EF?)

Спасибо

Answer 1

Для улучшения можно попробовать следующее:

• Используйте EF для получения DTO на вашем уровне данных, а затем используйте эти DTO для заполнения более богатых бизнес-объектов на вашем бизнес-уровне. Ваш пользовательский интерфейс только тогда должен будет ссылаться на бизнес-уровень.
• Как только вы создали богатые бизнес-объекты, вы можете начать усваивать часть логики из классов менеджера, эффективно очищая бизнес-уровень.

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

Если вы инкапсулируете логику в самом классе, вы можете быть более уверены в состоянии своего объекта, независимо от характера внешнего вызывающего.

Кстати, хороший вопрос.

Answer 2

Что касается вашего второго вопроса (после РЕДАКТИРОВАНИЯ), если вам нужно или вы хотите добавить функции к своим объектам EF, вы можете использовать частичные классы. Щелкните правой кнопкой мыши файл EDMX и выберите код просмотра.

Или, если этого недостаточно, вы можете оставить дизайнер и написать свои собственные классы с поддержкой EF.

Здесь есть (краткое) обсуждение обоих вариантов - http://msdn.microsoft.com/en-us/library/bb738612.aspx

Answer 3

ИМХО, ваш текущий макет в порядке. Для вашего пользовательского интерфейса вполне нормально ссылаться на слой «Данные», как вы его называете. Я думаю, что, возможно, ваша проблема возникает из-за терминологии. «Данные», которые вы описали, чаще всего называют слоем «бизнес-объектов» (BOL). Тогда общий макет будет состоять из уровня бизнес-логики (BLL), который является вашим уровнем «менеджеров» и уровнем доступа к данным (DAL). В вашем сценарии LINQ to Entites (при условии, что вы будете использовать это) - ваш DAL. Обычный эталонный образец будет тогда: -

ссылки на интерфейсы BLL и BOL. BLL ссылается на BOL и DAL (LINQ to Entites).

Посмотрите эту серию статей для более подробной информации.

Answer 4

Что касается вашего второго вопроса в разделе «РЕДАКТИРОВАТЬ»:

Если я не ошибаюсь, классы, сгенерированные EF, не запечатаны, и это PARTIAL классы, так что вы можете легко расширить их, не касаясь самих сгенерированных файлов.

Сгенерированный класс будет:

public partial class Planet : global::System.Data.Objects.DataClasses.EntityObject
{
 ...
}

так что вы можете легко создать свой собственный "PlanetAddons.cs" (или как вы хотите его называть) для расширения этого класса:

public partial class Planet 
{
 property int Population {get; set;} 
 ...
}

Довольно аккуратно, а? Не нужно создавать и создавать иерархии искусственных объектов ....

Марк

Answer 5

Я бы добавил DTO на ваш бизнес-уровень, которые являются представлениями "немого объекта" (т.е. только свойства) сущностей на вашем уровне данных. Тогда ваши классы «Менеджер» могут вернуть их, например:

class PlanetManager
{
    public static PlanetDTO GetPlanet(int id) { // ... }
}

и ваш пользовательский интерфейс может работать только со слоем BLL через POCO; менеджер (то, что я бы назвал классом Mapper) обрабатывает все преобразования между объектами и уровнем данных. Кроме того, если вам нужно расширить класс, вы можете иметь «виртуальное» свойство объекта DTO, и менеджер сможет преобразовать его обратно в его компоненты.

Answer 6

Ваш макет выглядит нормально. Я бы добавил слой Utility / Common

Веб-интерфейс
Бизнес Уровень
DataObjects
Служебный слой

Answer 7

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

Если вы не хотите, чтобы уровень представления знал о уровне доступа к данным, вам нужно создать несколько промежуточных классов, что, вероятно, потребует много работы. Так в чем же проблема с вашей текущей настройкой?