Действительно ли неправильно сделать объекты области, знающие об уровне доступа к данным?
Вы можете использовать Javascript, чтобы «щелкнуть» по указанной кнопке вкладки:
document.getElementById("default").click();
<!DOCTYPE html>
<html>
<head>
<title></title>
<style type="text/css">
.sight_img{
height: 80%;
width: 100%;
}
.tab {
overflow: hidden;
border: 1px solid #ccc;
background-color: #f1f1f1;
}
/* Style the buttons inside the tab */
.tab button {
background-color: inherit;
float: left;
border: none;
outline: none;
cursor: pointer;
padding: 14px 16px;
transition: 0.3s;
font-size: 17px;
}
/* Change background color of buttons on hover */
.tab button:hover {
background-color: #ddd;
}
/* Create an active/current tablink class */
.tab button.active {
background-color: #ccc;
display:block;
}
/* Style the tab content */
.tabcontent {
display: none;
padding: 6px 12px;
-webkit-animation: fadeEffect 1s;
animation: fadeEffect 1s;
}
/* Fade in tabs */
@-webkit-keyframes fadeEffect {
from {opacity: 0;}
to {opacity: 1;}
}
@keyframes fadeEffect {
from {opacity: 0;}
to {opacity: 1;}
}
</style>
</head>
<body>
<div class="tab">
<button class="tablinks" id="default" onclick="openCity(event, 'Description')">Description</button>
<button class="tablinks" onclick="openCity(event, 'Avalability')">Avalability</button>
<button class="tablinks" onclick="openCity(event, 'Itinerary')">Itinerary</button>
<button class="tablinks" onclick="openCity(event, 'Policy')">Policy</button>
</div>
<!-- // content-tabs-i // -->
<div id="Description" class="tabcontent">
<h3>Description</h3>
</div>
<div id="Avalability" class="tabcontent">
<h3>Avalability</h3>
</div>
<div id="Itinerary" class="tabcontent">
<h3>Itinerary</h3>
</div>
<div id="Policy" class="tabcontent">
<h3>Policy</h3>
</div>
</body>
</html>
<script>
function openCity(evt, cityName) {
var i, tabcontent, tablinks;
tabcontent = document.getElementsByClassName("tabcontent");
for (i = 0; i < tabcontent.length; i++) {
tabcontent[i].style.display = "none";
}
tablinks = document.getElementsByClassName("tablinks");
for (i = 0; i < tablinks.length; i++) {
tablinks[i].className = tablinks[i].className.replace(" active", "");
}
document.getElementById(cityName).style.display = "block";
evt.currentTarget.className += " active";
}
document.getElementById("default").click();
</script>4 ответа
Я боюсь, что Вы немного неправильно поняли намерение шаблона Репозитория.
Репозиторий предназначен для поведения как набор в оперативной памяти конкретного объекта области, обычно совокупный корень:
interface EmployeeRepository
{
List<Employee> retrieveBy(Criteria someCriteria);
void store(Employee someEmployee);
int countOf(Criteria someCriteria);
// convenience methods
Employee retrieveById(String id);
Employee retrieveBySSN(String ssn);
}
Клиенты этого кода понятия не имеют, является ли набор в памяти, как Вы имели бы для поблочного тестирования, или говорящий с картопостроителем ORM в некоторых случаях, или называющий хранимую процедуру в других или поддерживающий кэш для определенных объектов области.
Это все еще не отвечает на Ваш вопрос. На самом деле у Вас могли потенциально быть объекты области, имеют, сохраняют () и загрузка () методы, которые делегируют в правый репозиторий. Я не думаю, что это - правильный способ пойти, потому что персистентность почти никогда не является частью бизнес-домена, и это приводит Вашему объекту области больше чем одну причину измениться.
Проверьте этот связанный вопрос для более хаотичного.
В ответ на некоторые комментарии к этому ответу:
Допустимая критика. Однако я все еще смущен затем о том, как получить единственный объект области или набор связанных объектов области когда в контексте существующего объекта области. – gabriel1836
Скажем, у Сотрудника есть много Навыков. Я ничего не вижу неправильно с Репозиторием Сотрудника, называя Репозиторий Навыка как это:
// assume EmployeeRepository talks to a DB via sprocs
public Employee retrieveById(String id)
{
ResultSet employeeResultSet = this.database.callSproc("PROC_GetEmployeeById",
new Object[] { id });
List<Skill> skills =
new SkillRepository().retrieveBy(new EqualsCriteria("EmployeeId", id));
Employee reconstructed = new EmployeeFactory().createNew().
fromResultSet(employeeResultSet).
withSkills(skills).
build();
return reconstructed;
}
Другой маршрут вместо того, чтобы назвать Репозиторий Навыка, имейте вызов Репозитория Сотрудника, в этом примере, хранимая процедура для загрузки набора результатов для навыков, затем делегируйте к Фабрике Навыка для получения списка Навыков.
Разве я не могу позвонить в Репозиторий и издает ли он приказ к картопостроителю данных или загружается, объект, в оперативной памяти, является своим беспокойством, не так ли? – gabriel1836
Точно правильный. Я обычно дразню весь уровень данных в своих модульных тестах этот путь.
Да. Спросите себя, почему объект области знал бы о такой вещи? Даже, почему, но как? Вы собираетесь ввести свой DAL в Ваш Объект области?
Домен должен следовать, SRP просто живут все остальное. Когда Вы пересекаете свой домен, необходимо не знать, были ли те свойства заполнены через ленивую загрузку или гидратировались от инстанцирования.
Я записал модель предметной области, которая имела объекты DAL в них, и это был кошмар для поддержания. Затем я изучил NHibernate, и мой домен состоит из POCO's и их соответствующая бизнес-логика, которую я хочу инкапсулировать.
[Править]
Вот больше информации. Я только опозорился бы, если бы я пытался объяснить это. Я могу только говорить о реализации как пользователь. Вот большая статья об управлении Моделью предметной области. То, чем Вы интересуетесь, является реализацией перехватчиков и mixins.
С теми инструментами можно записать класс сотрудника следующим образом:
public class Employee
{
public Employee()
{
Skills = new List<Skill>();
}
public string Name { get; set; }
public IList<Skill> Skills { get; private set; }
public void AddSkill(Skill skill)
{
// Perform Domain specific validation here...
Skills.Add(skill);
}
}
Как Вы видите, мой доступ к данным должен сделать не, налагают на мой Доменный дизайн вообще.
Сделав некоторые дополнительные материалы для чтения и поиск соответствующего шаблона, я наткнулся на Шаблон Репозитория.
Из того, что я вижу, что это - точно предполагаемое решение, которое позволяет, чтобы Объекты области как Человек правильно делегировали запросы к соответствующему Картопостроителю Данных при оставлении Картопостроителя Объекта области и Данных полностью абстрагированным.
Я не согласен, я думаю, что объект домена может получить доступ к репозиториям через абстрактную фабрику.
public class Client
{
public void ChangeZipCode(string zipCode)
{
// This method access memory or database depending on the factory context
bool zipCodeExists = RepositoryFactory.Get<IZipCode>().Exists(zipCode);
this.zipCode = zipCode;
}
}
Используя этот паттерн, нет необходимости внедрять интерфейсы репозиториев по всему коду. а только фабрику репозиториев.
public abstract class RepositoryFactory
{
// Class operations
private static _globalInstance;
public static CreateGlobalInstance(RepositoryFactory factory)
{
_glocalInstance = factory;
}
public static I Get<I>()
{
return _globalInstance.Get<I>();
}
/////////////////////
///// this operation should be inherited by:
///// * NHibernateRepositoryFactory //
///// * Linq2SqlRepositoryFactory ////
///// * NUnitRepositoryFactory ///////
///// it depends in your context ////////////////////////
public abstract I GetRepository<I>();
}
Я делал это в течение многих лет без каких-либо проблем в своих модульных тестах.
Поэтому инъекция зависимостей требуется только в этом классе RepositoryFactory.