Если это тот подход, который вы хотите или должны использовать, вы можете сделать объекты sql частными классами внутри бизнес-объекта.
public class BusinessObject
{
private class SqlObject { }
}
Кроме того, используя частичные классы, вы можете при желании разделить их на отдельные файлы.
//in one file
public partial class BusinessObject
{
//business object implementation
}
//in another file
public partial class BusinessObject
{
private class SqlObject { }
}
Джоэл делает хорошее замечание в комментарии ниже: «SqlObject все еще может наследовать от общего типа, поэтому такие вещи, как информация о подключении, могут быть разделяется между этими «внутренними» классами ». это абсолютно верно и потенциально очень полезно.
В ответ на ваше изменение модульные тесты могут тестировать только общедоступные классы и функции (без использования отражения в ваших тестах). Единственный вариант, который я могу придумать, - это:
- сделать одну сборку для каждой пары объектов бизнес / sql
- изменение
private class SqlObject
на internal class SqlObject
- затем используйте
[InternalsVisibleTo("UnitTestsAssembly")]
для проекта
Кроме того, на этом этапе вам не нужно сохранять объект sql как вложенный класс. Вообще говоря, я думаю, что это, вероятно, добавит больше сложности, чем добавленная ценность, но я полностью понимаю, что каждая ситуация индивидуальна, и если ваши требования / ожидания подталкивают вас к этому, я желаю вам всего наилучшего. Лично я думаю, что я бы пошел с тем, чтобы сделать SqlObjects общедоступными (или внутренними с видимыми внутренними компонентами для модульного тестирования) и принять тот факт, что это означает, что классы sql доступны для всех бизнес-классов.
person
Timothy Carter
schedule
15.09.2009