ОРМ и Конструкторы

Question

Я просматриваю реализации .NET ORM, и у меня есть серьезный острый вопрос - есть ли реализации .NET ORM, для которых не требуются открытые свойства для каждого поля в базе данных? Когда я вижу такие примеры, как this , в моей голове раздается маленький колокольчик. Я твердо верю в инкапсуляцию, и меня заставляют открывать кимоно моих объектов только для того, чтобы они хорошо работали со средами персистентности, и это вызывает у меня хиби-джеби. Требуется ли такого рода доступность во всех ORM? Если нет, пожалуйста укажите мне примеры тех, кому это не нужно!

Answer 1

NHibernate поддерживает множественные стратегии доступа для учеников. Публичные свойства являются де-факто по умолчанию, но вы можете указать NHibernate для прямого доступа к полям вашего класса.

, например

<property name="CustomerName" access="field.camelcase-underscore" />

даст указание NHibernate использовать поле в вашем классе, объявленное так:

protected string _customerName;

Answer 2

Mindscape LightSpeed ​​привязывает только к полям - добавляйте свойства только для полей, которые вы хотите выставить (это only способ, которым это работает по явной причине инкапсуляции). Конечно, инструмент по умолчанию будет предоставлять свойства, но все они могут быть отключены.

Mindscape LightSpeed ​​O / R Mapper

Answer 3

Entity Framework также поддерживает это. Вы можете определить модификатор доступа для каждого свойства и независимо для получателя и установщика.

Answer 4

Харпер - Я чувствовал почти то же самое в отношении Linq-To-SQL, пока не понял, что все дело в том, как вы думаете об ORM ... это помогает думать о Linq2SQL как о не более чем "строго типизированной ADO. NET провайдер "...

Если вы просто хотите "быстро просмотреть" пару полей, то проекции LINQ вернут вам анонимные типы, которые содержат только те поля, которые вас интересуют. Это означает, что размер класса сущности не имеет отношения к производительности сети и памяти по вашему запросу.

На противоположной стороне спектра DataContexts (или UnitOfWork в других ORM) обычно являются тем, что вы используете и утилизируете как можно быстрее. Из этого следует, что объекты, которые они генерируют, должны быть ограничены в своей роли просто «держателями данных». Иными словами, если вы хотите создать сложные или долгоживущие объекты, проектируйте их отдельно от сущностей LINQ (т.е. разных классов) и просто используйте L2S для заполнения / создания экземпляров этих объектов.

Answer 5

LINQ to SQL может связываться с приватными полями, но не , но полностью поддерживает закрытый конструктор без параметров.

Answer 6

Вы имеете в виду, что вы хотите отобразить частных или защищенных членов в базу данных, а не делать их всех публичными? Один ORM, который я использовал, может это сделать Gentle.NET . Он стабилен, но в настоящее время не получает много обновлений.

Answer 7

Ознакомьтесь с уроком Скотта Гу. LINQ и MVC позволяют создавать бизнес-уровень, который оборачивает объекты БД в открытые и закрытые свойства.

http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx