О чем “SDK по сравнению с 'битами на проводных'” дебатах?
Здесь вы можете использовать командлет Group-Object, как показано ниже.
Если CSV похож на ниже
Name,Place
Joe,Florida
Joe,California
Joe,Florida,
Bob,Texas
Joe,Texas
Joe,Florida
Joe,Florida
Bob,Minnesota
Joe,California
Import-Csv -Path C:\Temp\Temp.csv | Group-Object -Property Name,Place
Вы можете поставить свою собственную логику, чтобы записать его в новый CSV.
5 ответов
Они не являются действительно взаимоисключающими. Это - больше континуума, но философия разработки позади систем имеет тенденцию гравитировать к одному концу или другому.
По существу биты на проводе говорят, что протокол связи достаточно прост, что он может быть описан внешним разработчикам через некоторых относительно простых (или даже неофициальный) спецификация. Это означает, что сервис может использоваться во всех видах непредвиденных путей и сервисной потребности потребителя не быть официальной поддерживаемой платформой.
С другой стороны, компании с монолитными предложениями как Apple и Microsoft имеют роскошь выбора другой философии, которая должна создать полный сквозной SDK. В теории это делает жизнь легче для разработчиков путем абстракции далеко сложностей базовых протоколов, одновременно освобождения продукта, чтобы сделать более сложные вещи и сокращения ошибки разработчика. Конечно, существуют все еще биты, и они все еще пробегаются через провод, и они могут быть перепроектированы. Однако это значительно будет (порядки величины), более трудные сделать, чем использовать протокол, который был разработан, чтобы быть понятным, особенно если он намеренно запутывался или шифровался для обслуживания деловых кругов.
Предположим, что клиент C должен говорить с сервисом S, обеспеченным поставщиком V. Если все, что Вы имеете, является SDK, то необходимо установить программное обеспечение SDK V поставщика на клиенте C, чтобы говорить с S. С другой стороны, если поставщик V документов точно, как говорить с сервисом S вниз к разрядному уровню, то можно записать собственное программное обеспечение на клиенте C, чтобы говорить непосредственно с сервисом S.
В то время как полезно в некоторых ситуациях знать то, что продолжается на разрядном уровне специально для поиска и устранения неисправностей, использование SDK поставщика может быть лучшим способом изолировать Вашу интеграцию от любых будущих изменений, которые поставщик может внести в их структуре обмена сообщениями.
Нельзя сказать, что не будет неудобства с точки зрения получения последнего SDK и такого, но по крайней мере если поставщик сделал их задание правильно, Вы не должны волноваться об изменении Вашего кода, просто с помощью их нового SDK.
Например, мы работали с компанией под названием ISD, которая специализируется на платежных продуктах переключателя. Мы кодировали к их SDK. В то время как их продукты прошли некоторое управление версиями, большинство, которое мы должны были сделать, обновить DLLs на клиентских машинах. DLL сохранил те же открытые интерфейсы.
Они не должны быть взаимоисключающими, это просто, что любой предоставляющий услугу или сфокусируется на SDK или проводном протоколе как их общедоступное направление клиента, обещанное интерфейс. У Вас мог быть сервис, который предоставил обоим, и позвольте своим клиентам выбрать, на каком сфокусироваться, но это могло бы быть роскошью.
Если Вы идете путем SDK, это очень важно для не, также обеспечивают биты на проводной спецификации, как это произошло в этой истории.