Где Вы выполняете свою проверку?
Вот как вы можете достичь того, что вы ищете (из кода / cli):
--create/select the file (locally) which you want to move to the folder:
~/Desktop> touch file_to_move
--move the file to s3 folder by executing:
~/Desktop> aws s3 cp file_to_move s3://<path_to_your_bucket>/<new_folder_name>/
Новая папка будет создана в вашей корзине s3, и вы теперь сможете выполнять cp , mv, rm ... операторы, т.е. управляют папкой как обычно.
Если этот новый файл, созданный выше, не требуется, просто удалите его. Теперь у вас есть ведро s3.
8 ответов
Multiple layers of validation go well with multi-layer apps.
The UI itself can do the simplest and quickest checks (are all mandatory fields present, are they using the appropriate character sets, etc) to give immediate feedback when the user makes a typo.
However the business logic should have the lion's share of validation responsibilities... and for once it's not a problem if this is "repetitious", i.e., if the business layer re-checks something that should already have been checked in the UI -- the BL should check all the business rules (this double checks on UI's correctness, enables multiple different UI clients that may not all be perfect in their checks -- e.g. a special client on a smart phone which may not have good javascript, and so on -- and, a bit, wards against maliciously hacked clients).
When the business logic saves the "validated" data to the DB, that layer should perform its own checks -- DBs are good at that, and, again, don't worry about some repetition -- it's the DB's job to enforce data integrity (you might want different ways to feed data to it one day, e.g. a "bulk loader" to import a number of Persons from another source, and it's key to ensure that all those ways to load data always respect data integrity rules); some rules such as uniqueness and referential integrity are really best enforced in the DB, in particular, for performance reasons too.
When the DB returns an error message (data not inserted as constraint X would be violated) to the business layer, the latter's job is to reinterpret that error in business terms and feed the results to the UI to inform the user; and of course the BL must similarly provide clear and complete info on business rules violation to the UI, again for display to the user.
A "custom object" is thus clearly "the only way to go" (in some scenarios I'd just make that a JSON object, for example). Keeping the Person object around (to maintain its "validation problems" property) when the DB refused to persist it does not look like a sharp and simple technique, so I don't think much of that option; but if you need it (e.g. to enable "tell me again what was wrong" functionality, maybe if the client went away before the response was ready and needs to smoothly restart later; or, a list of such objects for later auditing, &c), then the "custom validation-failure object" could also be appended to that list... but that's a "secondary issue", the main thing is for the BL to respond to the UI with such an object (which could also be used to provide useful non-error info if the insertion did in fact succeed).
A lot of this is more style than substance. I personally favor returning status objects as a flexible and extensible solution. I would say that I think there are a couple classes of validation in play, the first being "does this person data conform to the contract of what a person is?" and the second being "does this person data violate constraints in the database?" I think the first validation can, and should be done at the client. The second should be done at the middle tier. With this division, you may find that the only reasons the save could fail are 1)violates a uniqueness constrains, or 2)something catastrophic. You could then return false for the first case, and throw an exception for the other.
Валидация должна выполняться на всех трех уровнях.
Когда я нахожусь в проекте, я предполагаю, что делаю фреймворк, что в большинстве случаев не так. Каждый уровень является отдельным и должен проверять ввод всех слоев перед выполнением операции
Каждый уровень может иметь разные способы выполнения, не обязательно, что все они используют одно и то же, но в идеале все они должны использовать одну и ту же проверку с возможностью чтобы настроить его.
Вы никогда не хотите, чтобы плохие данные попали в базу данных. Таким образом, вы никогда не можете доверять данным, которые получаете от бизнес-уровня. Это необходимо проверить.
На бизнес-уровне вы никогда не можете доверять уровню пользовательского интерфейса, и вы должны проверить его, чтобы предотвратить ненужные вызовы уровня базы данных. Слой пользовательского интерфейса работает таким же образом.
Кроме того, пользовательский интерфейс может передавать данные, необходимые для создания объекта Person, через какой-то объект PersonBuilder, чтобы создание объекта консолидировалось на уровне домена / бизнеса, и вы могли сохранить объект Person в состоянии, которое всегда согласовано. Это имеет больше смысла для более сложных объектов, однако даже для простых хорошо централизовать создание объекта, так же, как вы централизовали сохранение и т. Д.
Если уровень R ближе к пользователю (или любой поток ввода, который вы не контролируете), чем уровень S, затем уровень S должен проверять все данные, полученные с уровня R. Это не означает, что уровень R не должен проверять данные. Для пользователя будет лучше, если графический интерфейс предупредит его о том, что он совершил ошибку, прежде чем он попытается совершить новую транзакцию. Но независимо от того, насколько пуленепробиваемая проверка в вашем графическом интерфейсе, следующий уровень не должен доверять тому, что какая-либо проверка имела место.
Это предполагает, что ваша база данных полностью находится под вашим контролем. В противном случае у вас проблемы посерьезнее.
Просто быстрый (и, надеюсь, полезный) комментарий: когда вам интересно, где разместить проверку, попробуйте сделать вид, что скоро вы собираетесь полностью воссоздать свой слой пользовательского интерфейса, используя технологию, с которой вы еще не так хорошо знакомы **. Постарайтесь исключить из этого уровня любую бизнес-логику, похожую на валидацию, которую, как вы точно знаете, вам придется переписать в новой технологии.
Вы »
Единственные важные моменты:
- С точки зрения внешнего интерфейса (-ов) средний уровень должен выполнять всю проверку, вы никогда не узнаете, будет ли кто-нибудь собирается попытаться обойти вашу внешнюю проверку, поговорив напрямую с вашим Средним уровнем (по любой причине)
- Средний уровень может решить делегировать часть этой проверки уровню БД (например, ограничения целостности данных)
- Вы может при желании дублировать некоторую проверку в пользовательском интерфейсе, но это должно быть сделано только для повышения производительности (чтобы избежать повторных обращений к среднему уровню для распространенных сценариев, таких как отсутствие обязательных полей, неправильно отформатированные данные и т. д.) Эти проверки никогда не должны заменять их на среднем уровне
Я не согласен с комментарием Дэвида Басараба о том, что одни и те же проверки должны присутствовать на всех уровнях. Это бросает вызов парадигме ответственности слоев по одной причине. Во-вторых, хотя основная цель состоит в том, чтобы сделать уровни (или компоненты) слабо связанными, также важно, чтобы уровень ответственности (и, следовательно, доверия) был наделен слоями. Хотя может потребоваться дублирование некоторых проверок в пользовательском интерфейсе и бизнес-уровне (поскольку уровень пользовательского интерфейса может быть обойден попытками взлома), тем не менее, не рекомендуется повторять проверки на каждом уровне. Каждый уровень должен выполнять только те проверки, за которые он отвечает. Самый большой недостаток при повторных проверках на всех уровнях - избыточность кода, которая может вызвать кошмар обслуживания.