Там какие-либо отрицательные причины состоят в том, чтобы использовать решение N-Tier? [закрытый]
Просто помните, что .equals(...) должен быть реализован классом, который вы пытаетесь сравнить. В противном случае, не так много смысла; версия метода для класса Object выполняет то же самое, что и операция сравнения: Объект # равно .
Единственный раз, когда вы действительно хотите использовать оператор сравнения для объектов, является Вы сравниваете Enums. Это происходит потому, что за один раз имеется только один экземпляр значения Enum. Например, с учетом перечисления
enum FooEnum {A, B, C}
У вас никогда не будет более одного экземпляра A за один раз, и то же самое для B и C. Это означает, что вы можете написать такой метод:
public boolean compareFoos(FooEnum x, FooEnum y)
{
return (x == y);
}
И у вас не будет никаких проблем.
6 ответов
Я предполагаю, что довольно большая оборотная сторона - то, что дополнительный объем кода, который необходимо написать, управляйте и поддержите для маленького проекта, может просто быть излишество.
Это - все вниз к тому, что подходит для размера проекта, ожидаемого срока действия заключительного проекта и бюджета! Иногда, пока выполнение вещей 'правильно' обращается, делание чего-то немного более 'легкого' может быть правильным коммерческим решением!
это имеет тенденцию брать неопытную команду дольше для создания 3-уровневый. Это - больше кода, так больше ошибок. Я просто играю защитника дьявола все же.
Как с чем-нибудь абстракция создает сложность, и таким образом, сложность выполнения N-tiered должна быть правильно выровнена по ширине, например, N-tiered на самом деле приносит пользу системе? Будут маленькие системы, которые будут работать лучше всего с N-tiered, хотя многие из них не будут.
Кроме того, даже если Ваша система является маленькой в данный момент, Вы могли бы хотеть добавить больше опций к ней позже - не идущий, N-tiered мог бы consitute своего рода технический долг с Вашей стороны, таким образом, необходимо быть осторожными.
Поскольку Вы хотите возможность способности распределить слои на различные физические уровни (я всегда использую "уровень" для физического, и "слой" для логического), необходимо думать дважды прежде просто поместить все в один класс, потому что у Вас есть основные рефакторинги, чтобы сделать, если или когда действительно необходимо начать распределять.
Единственный недостаток является сложностью, но действительно как трудно это, чтобы добавить некоторые объекты области и связать со списком их в противоположность использованию набора данных. Вы не должны даже создавать три отдельных проекта, можно просто создать 3 отдельных папки в рамках веб-приложения и дать каждому пространство имен как, YourCompany. YourApp. Домен, YourCompany. YourApp. Данные, и т.д.
Большое преимущество имеет более гибкое решение. Если Вы начинаете писать свое приложение как информационно-центрическое приложение, сильно связывая Ваши страницы веб-форм с наборами данных, Вы собираетесь закончить тем, что делали намного больше работы, позже мигрирующей на более доменную центральную модель, когда Ваша бизнес-логика растет в сложности.
Возможно, в ближайшей перспективе Вы фокусируетесь на простом решении путем создания очень простых объектов области и заполнения их от наборов данных, затем можно добавить бизнес-логику к ним по мере необходимости и пристроить более сложный ORM по мере необходимости или использовать nhibernate.
Я боролся бы за N разделенный на уровни подход, даже если это - маленький проект. При использовании инструмента ORM как codesmith + nettiers, Вы сможете быстро установить проекты и разрабатываете код, который решает Ваши бизнес-проблемы быстро.
Это уничтожает меня, когда Вы запускаете новый проект, и Вы проводите дни, сидя без дела прялки, говорящие о том, как "архитектура" должна быть спроектирована. Вы хотите провести время, решая бизнес-проблему, не решая проблемы, которые другие люди решили для Вас. Используя ORM (это действительно не имеет значения, который, просто выберите один и придерживайтесь его) помочь, Вы получить начальную тягу поможете сохранить Вас сфокусированными на целях проекта и не отвлечь Вас пытающийся решить проблемы "архитектуры".
Если в конце дня архитектор хочет пойти один подход проекта, нет никакой причины, Вы не можете создать app_code папку с папкой BLL и DAL для разделения кода на данный момент, который поможет Вам переместиться в решение N-Tiered позже.