Расположение проекта платформы Объекта.NET (архитектура)
Строковое значение, которое «кажется пустым, но имеет длину 2 символа», называется пробелом , а не пустым , не пустым , не пусто .
Используйте функцию Trim (или ее младший брат Trim$), чтобы убрать начальные / конечные пробельные символы, а затем сравните результат с vbNullString (или ""):
If Trim$(value) = vbNullString Then
Функция Trim не удаляет неразрывные пробелы. Вы можете написать функцию, которая выполняет:
Public Function TrimStripNBSP(ByVal value As String) As String
TrimStripNBSP = Trim$(Replace(value, Chr$(160), Chr$(32)))
End Function
Она заменяет неразрывные пробелы на ASCII 32 («нормальный» пробел), затем обрезает ее и возвращает результат.
Теперь вы можете использовать его для проверки по vbNullString (или ""):
If TrimStripNBSP(value) = vbNullString Then
Функция IsEmpty может использоваться только с Variant (возвращает только значимый результат). учитывая Variant в любом случае), чтобы определить, содержит ли этот вариант значение.
Функция IsNull имеет чрезвычайно ограниченное использование в VBA, размещенной в Excel, и не должна быть необходимой, поскольку на листе Excel ничего не будет Null, особенно строка длиной 2. [ 1125]
7 ответов
Вы могли попробовать следующее для улучшения вещей:
- Используйте EF, чтобы выбрать DTOs в Вашем уровне Data, затем использовать эти DTOs для заполнения более богатых бизнес-объектов в уровне Business. Ваш UI должен был бы только затем сослаться на уровень Business.
- После того как Вы создали богатые бизнес-объекты, можно начать усваивать часть логики от классов менеджера, эффективно очистив бизнес-слой.
Я лично предпочитаю более богатую модель по модели менеджера, потому что, как Вы говорите, Вы заканчиваете с загрузкой статических методов, которые Вы inevitibly заканчивают тем, что объединили в цепочку вместе в других статических методах. Я нахожу это и слишком грязным и, что еще более важно, тяжелее чтобы понять и гарантировать непротиворечивость Ваших объектов в любом данном моменте времени.
При инкапсуляции логики в самом классе, можно быть более уверены в состоянии объекта независимо от природы внешнего вызывающего абонента.
Хороший вопрос между прочим.
Что касается Вашего второго вопроса (после РЕДАКТИРОВАНИЯ), если Вы нуждаетесь или хотите добавить опции к своей EF, возражает, что можно использовать частичные классы. Щелкните правой кнопкой по файлу EDMX и выберите код представления.
Или если это не достаточно для Вас, может угробить разработчика и записать, что Ваш собственный EF включил классы.
Существует (краткое) обсуждение обеих опций здесь - http://msdn.microsoft.com/en-us/library/bb738612.aspx
Я не эксперт, но это звучит довольно хорошим мне. То подобное тому, что я имею в своих решениях, кроме меня просто, объединяет проект EF с бизнес-проектом. Мои решения не являются настолько большими, и мои объекты не требуют большой аналитики, таким образом, ее штраф для меня. У меня также есть тонна различных методов для каждого из моих статических классов помощника.
Если Вы не хотите уровня представления, знающего об уровне доступа к данным, то необходимо создать некоторые посреднические классы, которые, вероятно, были бы большой работой. Таким образом, какова проблема с Вашей текущей установкой?
По моему скромному мнению, Ваш текущий макет прекрасен. Совершенно нормально для Вашего UI сослаться на уровень 'Data', как Вы называете его. Я думаю, что, возможно, Ваше беспокойство возникает из-за терминологии. 'Данные' Вы описывали чаще называемый уровнем (BOL) 'бизнес-объектов'. Общее расположение должно было бы затем иметь слой бизнес-логики (BLL), который является Вашим уровнем 'Managers' и уровнем доступа к данным (DAL). В Вашем сценарии LINQ к Entites (предположение Вас будет использовать это) является Ваш DAL. Нормальный ссылочный шаблон затем был бы:-
Ссылки UI BLL и BOL. Перезаборы BLL BOL и DAL (LINQ к Entites).
Взгляните на этот ряд статей для большего количества детали.
Что касается Вашего второго вопроса в разделе "EDIT":
Если я не ошибаюсь, классы, сгенерированные EF, не изолируются, и они - ЧАСТИЧНЫЕ классы, таким образом, Вы могли легко расширить тех, которые, не касаясь самих сгенерированных файлов.
Сгенерированный класс будет:
public partial class Planet : global::System.Data.Objects.DataClasses.EntityObject
{
...
}
таким образом, можно легко создать собственный "PlanetAddons.cs" (или независимо от того, что Вы хотите назвать его) для расширения этого класса:
public partial class Planet
{
property int Population {get; set;}
...
}
Крутой, а? Никакая потребность произойти и создать искусственные иерархии объектов....
Marc
Ваше расположение смотрит хорошо. Я добавил бы уровень Utility/Common
Сеть UI
Бизнес-слой
Dataobjects
Уровень Utilities
Я добавил бы DTOs к Вашему уровню Business, которые являются "немыми объектными" представлениями (т.е. только свойства) Объектов в Вашем слое данных. Затем Ваши классы "менеджера" могут возвратить их, такие как:
class PlanetManager
{
public static PlanetDTO GetPlanet(int id) { // ... }
}
и Ваш UI может только иметь дело с уровнем BLL через POCOs; менеджер (что я назвал бы классом "Картопостроителя") обрабатывает весь перевод между объектами и слоем данных. Также, если необходимо расширить класс, у Вас может быть "виртуальное" свойство на объекте DTO и сделать, чтобы менеджер перевел тот назад в его компоненты.